You throw me out off the window and I return back…
Our versioning scheme is weird, I keep typing the useless “1.” forever and last discussions led to nowhere. Although I disagree, we at least agreed that there should be some major milestone that is released with the new major version bump. But it does not look like there’s gonna be something big enough - React is a slow process, API V3 is nowhere near and we keep adding lots of small features.
If we stuff some stabilization as well, Rails 6… I would agree.
Though as 1.23 would be last 1.x release, we would need to keep longer support in my opinion.
In my opinion the version number is just a number, doesn’t really matter to me if we call it 1.24, 2.0 or 542.1.5. I’m fine with jumping to 2.0 so we can stop discussing this every other version and focus on making the versions better, and dropping mysql support is actually a breaking change that even makes sense semver-wise.
Exactly what I was just about to mention.
With a steady release modle, this should be the main reason to consider for major versioning bumps. Especially if you do not need to charge your customers for every new version The idea of “bump maior version only if we have a lot of highlits” does not work very well with the rapid release model in my opinion.
We have decided to postpone MySQL drop to 1.25 instead of 1.24 to give users extra three months. So with this in mind, I propose to refer the version which will only work on PostgreSQL in this combined manner: “1.25/2.0”. It’s also a good opportunity to communicate the version change, so users have more time to understand.
@core - please vote or comment. let’s make 1.25=2.0 if there are no major objections. this will also give all who want some more major changes for 2.0 time to work on them
With the long list of additional changes planned in 1.25 (Foreman <strike>1.25</strike> 2.0 schedule and planning), and the general support we had in the poll in July, unless anyone raises a significant objection in the next week or so - we’ll start changing the upcoming release to be Foreman 2.0. @core - this is your last call to speak up or change your mind
Right now, IIRC the only “versioned” deprecation we have in core is for MySQL support in 1.25.
I am toying however with the idea of taking advantage of this bump to drop some api endpoints and parameters that have been “deprecated” over the years but never dropped since we haven’t done APIv3 yet.
I expect so, unless there is any reason not to - most likely it would be easier to keep them in sync since that’s what all our tooling expects.
We recently had an off the cuff discussion in packaging around moving away from the foreman-proxy nomenclature to a smart-proxy nomenclature across the ecosystem to avoid having a split (or vice-versa moving smart-proxy to foreman-proxy) usage. This likely needs a separate thread, but would you include that as a good thing to do as part of this change?
If that’s only a name change, than I believe it’s ideal timing. If that’s some kind of big change I’d suggest not to tight your hands to it but I’d not be against.
I’d suggest considering also Foreman Capsule Proxy (or variants) to take into account.
The idea of “bump maior version only if we have a lot of highlits” does not work very well with the rapid release model in my opinion.