Invite Ronny Vedrilla to team.

[carltongibson]

I'd like to propose adding Ronny @GitRon to the team for crispy-tailwind.

I can vouch for Ronny personally. He's a lovely person. And crispy-tailwind could do with more bandwidth.

@smithdc1 I don't believe you're actively using tailwind right? Whilst I am, I'm not currently using crispy for that (as part of my experiment into What Now? given the Django 4.x+ forms changes). Ronny is going both, and is well placed to take the lead here.

Whilst we're here, I'd state my thoughts on the scope/goals:

• Keep it small — it's a demonstration of what you can do, and a starting point, not an always solution.
• Link to and document other things in How-Tos
• Encourage folks to override what they want to in their own projects.

[smithdc1]

Hi @carltongibson & @GitRon, Happy New Year to you both.

This is great. 🎉 The project could certainly do with more bandwidth, also my knowledge of Tailwind is pretty basic.

Carlton -- Are you able to help with the invite? I had a look and got a bit lost on what I should do. It seems more complicated than last time I looked!

[carltongibson]

OK, done, I think 😅

I invited Ronny to the crispy forms core team, added access to all the crispy repos there, and set the Triage role (which should allow close/merging/... PRs and such.)

@GitRon Welcome aboard! Go! 🎉 Shout if you want input, or if the permissions aren't right or... — Both @smithdc1 and I watch the repos say if you need anything. 🎁

[GitRon]

Thanks, guys! It's the first time for me maintaining a package together with other people!

Hence I have some questions:

• Am I supposed to merge PRs as well?
• Who's doing a release and when? Merged branches are nice but if it's not released, it basically didn't happen.

[carltongibson]

Yep @GitRon merge 'em!

If you can do things like change notes and what not, we can check over and do the release (but so can you: we just need to get the permissions lined up)

[GitRon]

Good point! Forgot about the change notes in the last ticket. Will add it for my current PR.

[GitRon]

OK, once #146 is merged, I'd suggest a release. The last one was ages ago and @smithdc1 did already some changes to the metadata in October which never saw the light of day 😅

Are you ok with this?

[carltongibson]

Yep, sounds good.

If you get it ready, or as close as you can, then that's amazing. It really helps.

[GitRon]

The PR is merged. Nothing open from my side 🙂

Supplemental: Should we go to version 1.0? The package might be a little buggy but I still think it's stable enough for 1.x

[smithdc1]

How about switching to CalVer? 🤔

[carltongibson]

Yeah! +1 for CalVer.

I personally favour two digit year, plus number of release in year. So 24.1 it would be.

(Some folks like the extra month... 24.1.1 but it seems a bit much to me unless you're like Ubuntu.)

[GitRon]

Hm, I think it's great for certain packages like my meta-package-updater because it doesn't contain any code.

I like semVer a lot because when I update the package I know what to expect. Bugfix release? No need to worry. Major release? Let's have a deep dive into the changelog. CalVer Doesn't provide that.

My 5c on the topic 🙂

[justinmayer]

I was going to suggest that I volunteer to help out by automating releases via AutoPub, but I don't believe it supports CalVer (yet). 😊

[carltongibson]

My jaded take on breaking changes is that they're all breaking changes. 😅 Folks complain no matter what. SemVer writes checks poor maintainers can't cash: let 'em read the release notes.

(This may apply all the more for template heavy packages, where folks write CSS/JS to match the HTML exactly...)

Happy to go with the consensus though.

[justinmayer]

Folks will indeed complain no matter what, but I'm not sure that's a good justification for CalVer. I prefer SemVer because it at least conveys some information regarding what lies within, whereas CalVer feels to me like an unnecessary capitulation.

SemVer is a guide for users and not a promise, and therefore to me it's not akin to writing checks doomed to bounce. As for folks who have an expectation that SemVer is a promise, I say let those misguided folks complain as much as they like.

Just my take on this topic, of course. 😊

[GitRon]

In general, I agree with @justinmayer but Carlton has a point in this case:

(This may apply all the more for template heavy packages, where folks write CSS/JS to match the HTML exactly...)

[carltongibson]

@justinmayer Can we get you to DjangoCon and we can wrestle for it 😜

🎁

...some information...

Conversely I often find when was this release to be more insightful than a major version number, but yes, there are different points to make.

I'm not hung up. +1 to the majority view

[GitRon]

I've already bought tickets 🙃

[GitRon]

The discussion about having a release ASAP got a little bit derailed 😅

If @justinmayer could to the changes for the auto-versioning reasonably soon, I'd take this as a killer argument pro semVer. If he can't do that (which is of course perfectly fine!), I'd put up a vote between calVer and semVer and do a 0.6.0 release so we get all the new stuff shipped out-

Can we agree on that roadmap? 🙂

[carltongibson]

Don't let the version number delay you! (Not that much hangs on it 😅)

[GitRon]

I think I can't do the release, right? The question is: Who can? 😅

[carltongibson]

@smithdc1 can. But you can get it close 😉.

(The actual twine upload bit is the least of it... — but maybe we can get you added on PyPI too.)

[smithdc1]

https://github.com/django-crispy-forms/crispy-tailwind/blob/main/.github%2Fworkflows%2Fpublish.yml

We've a workflow setup. It's "just" a matter of creating a GH Release. I'm happy to do that, just need to make sure version number is updated etc.

[justinmayer]

If @justinmayer could to the changes for the auto-versioning reasonably soon, I'd take this as a killer argument pro semVer. If he can't do that (which is of course perfectly fine!), I'd put up a vote between calVer and semVer and do a 0.6.0 release so we get all the new stuff shipped out

I would be more than happy to set that up. The configuration I would recommend would include publishing via PyPI's new Trusted Publisher system, and it also would automatically create the GitHub Release as part of the release process.

[GitRon]

@smithdc1 What do I have to do? Just update the version number somewhere in the code?

@justinmayer I'd be happy about a PR, sounds like a neat solution. I guess the others agree?

[smithdc1]

@GitRon https://github.com/django-crispy-forms/crispy-tailwind/blob/main/crispy_tailwind%2F__init__.py

Just here I think.

Thanks for all your efforts here!

[GitRon]

Hi @smithdc1 - I've created a PR with the version dump and updated the changelog: #148

Do you need anything else?

[GitRon]

@smithdc1 Code has been merged, you can do the release now I guess 😊

[smithdc1]

Thank you @GitRon ! ❤️

https://pypi.org/project/crispy-tailwind/1.0.0/ 🎉