x.y.z vs X.Y.0 releases

[mumbel]

Milestones for for x.y.z exist concurrently with the next "major" X.Y.0 release and typically to date the x.y.z is not released, only the X.Y.0. Would it it be procedurally expensive to go ahead and release both when the X.Y.0 released?

From a shared project user, yes it's possible the x.y.z always introduced a requirement to get exclusive checkout for upgrade, while the X.Y.0 do typically always do this, so getting that x.y.z is sometime useful for bug fixes.

Is it just a case a too much testing to do a release, even a throwaway "if x.y.z doesn't work, you should just upgrade to X.Y.0x

@ryanmkurtz @ghidra1

[ryanmkurtz]

I wasn't aware of any link between exclusive checkout and the way we do our versioning. Or was that a suggestion?

The general guidelines we follow for bumps to major.minor.patch are:

• major: Big new features or big API breaking changes.
• minor: Somewhat regular releases of the master branch.
• patch: As-needed releases of the patch branch, usually containing just bug fixes, processor bug fixes, and other minor changes that don't require extensive testing.

As you observed, when we are about to make a major or minor release, we just ditch the current patch development branch because all of those changes are going to be in the major/minor release. Sometimes one of these release might require a server upgrade, so I do see the value in potentially releasing the patch branch in that scenario, if it contains meaningful fixes. We'll have to have an internal discussion about it.

[mumbel]

Definitely just bringing it up since it's worth asking at least, in the end it's the user's workflow and team coordination that this effects. if there's a real problem, not much ghidra devs can do.

For example the upcoming 11.3.3 and 11.4.0, the odds of needing to get exclusive to upgrade are higher in 11.4.0. Having both released, even if 11.3.3 is "buyer beware" would be a nice to have for larger teams doing shared projects where some bugfixes are nice to get (and yes still small chance even that version would require exclusive to upgrade).

I've had this convo before about versioning and my take away was "which version?" since each processor module has its own as well as ghidra. And while yes I agree with your description of major minor patch, I don't believe that's held true, some things just don't get captured and trigger this in a patch version (I'm 99% sure I've had to get exclusive to go from like a a.b.2 to a.b.3 in the past)

this was meant as a client only conversation, as AFAIK the only real server changes where an upgrade was needed were things like fix log4j and things like having to bump up the jdk version if the server had to upgrade; otherwise, it's always been backwards compatible.