Hi Christopher- Thanks for kicking this off. I think JB’s idea of a PR draft document is the way to go so we can layout specifics.
In addition to code-level API/SPI changes, I think it is important that we address boot-time, configuration, and packaging changes that would impact DevOps teams. For example— Changing env/system properties of startup scripts should only be done in a major or minor version change. Admins should be confident that a unzip and run update works between patch versions (and most minor versions). Exception exception: Security update work around (ie log4j2 vulnerability work-around that adds a -D property at boot time) Changes to CLI names or required params should only be in major version. These commands are often used for admin tasks and certifying startup of brokers at runtime. Configuration parameter default values should only change between major versions. ..etc Thanks, Matt Pavlovich > On Dec 9, 2024, at 7:21 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi Christopher > > Thanks for starting the thread. > > We have several different examples on SemVer in Apache projects. > More than pure SemVer, I think we should clearly state and document > what we agreed on ActiveMQ. > > Imho, we should: > - major version should focus on breaking changes (user facing) > - minor can contain upgrade (including important ones) as soon as it > doesn't break > - micro is just for patch (minor upgrades and fixes) > and with associated LTS/LTM series. > > I like the Accumulo documentation, but a bit "abstract": for ActiveMQ, > I think we can be more "concrete" about the kind of changes (for both > Artemis and Classic). > > I propose we start a website PR draft documenting versioning and > LTS/LTM (we can contribute all together on the PR). > > Regards > JB > > > On Mon, Dec 9, 2024 at 2:04 PM Christopher Shannon > <christopher.l.shan...@gmail.com> wrote: >> >> There's been some discussion brought up about versioning as part of the JDK >> 17 thread for Artemis so I wanted to break it out into another thread. >> >> That thread made it apparent that the project doesn't really have any >> guidelines on how we do versions so I think it would be a good idea to >> decide on our versioning policy going forward and what we are allowed to >> change between major/minor/patch releases. We don't have to actually adopt >> SemVer 2.0 but it's a good starting point for discussion. >> >> As a good example on another project, I'm also on the PMC for Apache >> Accumulo and we have a policy defined for long term releases and we also >> adopted SemVer 2.0 and have a well documented policy on it: >> https://accumulo.apache.org/contributor/versioning >> >> Accumulo has also defined the public API and what is actually guaranteed to >> change only in accordance with SemVer 2.0: https://accumulo.apache.org/api/ >> Any code outside the public API does not need to follow SEMVER and can >> change in any release. This reduces the burden because trying to be super >> strict for all code would be pretty hard to do and not necessary. >> >> Thoughts? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
