1 Reply Latest reply on Feb 7, 2008 6:38 AM by Carlo de Wolf

    Versioning Conventions

    Andrew Rubinger Master

      How will we proceed with versioning conventions in the EJB3 Component?

      Originally Carlo had set up a relationship between RC number and release such that RC12 == 0.12.0 for each project comprising the EJB3 component.

      However, this becomes invalidated as we've added modules to the project which may or may not change with each subsequent release.

      I'll propose a format of X.Y-SNAPSHOT for trunk, to be named X.Y in a branch (in preparation for tagging) and X.Y.Z for each release, where the following applies:

      X = Major version; rewrites, no guarantee of backward-compatibility
      Y = Minor version; typically each release with new features or API
      Z = Patch version; small changes made as release is prepared

      We may then build a matrix in which EJB3 Release N consists of 0.3.0 ext-api. 0.1.3 core, etc, eg.

      I'm not married to the above, but I'd like some sort of convention; things are getting messy in there.


        • 1. Re: Versioning Conventions
          Carlo de Wolf Master

          See http://docs.jboss.org/process-guide/en/html/release-procedure.html.

          Now 0.12.0 is the baseline for most components as they're coming out of the RC12 codebase. So yes, some components will start leaping forward while other (/new) components will start of at 0.1.0.

          We'll not create branches just because we can. We'll only create them if we need to backport (which we'll rarely (if ever) do).

          As long as we're at major 0, it's an unsupported component. We don't care about backwards compatibility. Starting with major 1 it's a supported component. We'll keep it at major 1 as long as we can maintain backwards compatibility (which should be a very long time).

          Within majors we only support the latest minor. So in actuality we only have branches for the major versions (which should be one (== trunk)).

          Going to a new major should result in End-Of-Life of the previous major (so preferably ~3 years after it's release).

          As long as we don't use any snapshots and have a clean test suite we can release at any time. So hotfixes can always go into trunk. If not, then we do actually branch.

          There could be a product matrix, if we define some proper component plugin points. For now the ejb3 plugin depends on core which has transitive dependencies on other ejb3 components. This should be properly handled in the assembly.

          Same goes for AS & Embedded, they suck in a specific version of core as well.