Agorakit : Users & developers
Agorakit : Users & developers
Semantic versioning
Are we using semantic versioning? If not, could we change to that?
If we followed that, requiring a higher version of PHP would have made 1.9.3 the 2.0 release instead. I think it's a best practice to follow this unless there are strong reasons not to.
First, imagine having 1.9.2 installed on PHP 8.0 and assuming this was a patch release. You'd completely break your site.
Second, imagine we had a security patch and needed to release it immediately. We now have no path to getting a quick fix to a PHP 8.0 user. Because going from 1.9.2 to 1.9.3 involves a major PHP upgrade, there's no version number space left for a security patch or other backwards compatibility.
Third, it makes it clearer what the next release version should be. "Saving up" for a "big" major point release stops being a thing to worry about.
I think so. At least, I think we intend to.
Great idea! I was supposed to be wanting doing this, then I stopped, approaching the supposedly incredible 2.0 release :-)
Let's stop this and follow best practices.
Do you have any recommandation as to how to proceed? I know what semantic versioning is in theory, but how to apply it to the project now and put everything back on track?
I suggest we leave the current releases as-is.
It's tempting to mess with releases retroactively, but I think it can create more confusion than it's worth.
Let's simply be clear about patch-level changes, minor changes, and backwards-incompatible changes going forward, and use the changelog to determine the next appropriate version number.
Is it a good idea to release a 2.0 quite soon because of recent PHP requirements changes ?
Or we continue 1.x where x can be > 9 ?
I'd simply evaluate each new release based on the new criteria. It's fine to release 1.10 if the next release is a minor-point.
I'd define "breaking BC" in our context as:
A good example of an issue that would cause us to move to 2.0: https://github.com/agorakit/agorakit/issues/524
Changing the namespace would definitely be a BC break.
Since we have a few backwards-compatibility breaks identified now, I grouped them under a '2.0' milestone to see if we can roll them out together and avoid repeated breaks.
Good idea!
i'll fix more little stuff and hopefully will dedicate a day or two on the bigger stuff in the following week.
I just read the 2.0 milestone intro, it's encouraging!
Good job!
I will find more time to help after 04/15.
BTW, would you have a look at https://github.com/agorakit/agorakit/pull/552 ? It is ready to merge imho!
I just re-read the whole changes for location (on my phone though), and it seems ready to go. Allow me access to a real computer and without kids around and I'll merge it 😉
Thank you for this big change, with more features and less lines of code !
You're welcome. Thank you for reviewing. You gave me some privileges so I think I could merge myself. But I leave you the honour, so you can review once more -- on a computer -- if you like!
It's merged!
I just enhanced a bit the location form using fieldset and some margins here : https://github.com/agorakit/agorakit/pull/590 .
Back to the initial discussion : I think I will start working on the bigger changes for the 2.0 milestone. What would you recommend, I keep working with PR's ? I don't like the idea of creating a separate branch because I'm not that proficient with git. But you can convince me otherwise :-)
You know what, I will learn about branches first :-)
/me learns he is already working with branches since a few months.
But how it works if we want to release a breaking changes 2.0 version in a few months, based on several parallels pull requests ?
Correct me if I'm wrong, but we can have a 2.0 branch, and have several pull requests being merged into this 2.0 branch as we work on 2.0 stuff. Then when it's ready to be released, we merge this 2.0 branch into main, and then release 2.0.
> Correct me if I'm wrong, but we can have a 2.0 branch, and have several pull requests being merged into this 2.0 branch as we work on 2.0 stuff. Then when it's ready to be released, we merge this 2.0 branch into main, and then release 2.0.
That is wrong. 😅
Simply merge the changes into `main`. You choose the version number at the time of release, not prior.
If you needed to release a patch to an older release (which should be tagged), you can check out that tag, create a branch from it, and then target a PR to that branch, then release it.
Ah that's simpler great!
I think it would be nice to release at least one more version before the big changes in upcoming 2.0. it would be called 1.10 ? In order to provide the nice location additions of Odile which are now stable enough.
Also, if you don't mind, next time we talk, can you show me the proper process to make a new release 😅
> location additions
if you can wait until next week, I'd like to complete that with the small menu we have planned (without any admin page, and hence without any structural change)
Of course, I just want to release something stable before 2.0
> it would be called 1.10 ?
If there are no backwards-incompatible changes, yes.
If there is, it would simply become 2.0, and then our next break would be 3.0 instead.
> can you show me the proper process to make a new release 😅
I don't see anything wrong with the current releases, they are nicely documented & tagged from my perspective, but happy to discuss if there are improvements you're hoping to make.