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.
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.
With the long list of additional changes planned in 1.25 (Foreman 1.25 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?