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.

• If it's a patch, it's 1.9.4.
• If it's changed functionality but not backward-compatibility ("BC") breaking, it's 1.10.
• If it's breaking BC, it's 2.0.

I'd define "breaking BC" in our context as:

• Requiring a higher PHP or MySQL (or other OS-level library) version.
• Moving a full version of Laravel.
• Changing an API (or feed or integration) in a way that could cause existing calls to break.
• Anything requiring a non-standard upgrade process.
• Making a large enough app-level change that an extension or customization may reasonably break (this may be a judgment call).

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)