Noel J. Bergman wrote:
Danny,
This is what we had previously agreed upon. As Stefano points out, the
"catch" is the subjective understanding of what makes something a major,
minor or point release. And I would add some degree of risk assessment to
the mix. A point release should have very little risk when upgrading. A
minor release may have a bit more, and a major release even more.
I agree, and I agree that also the "degree of risk" is something
subjective. Everyone will see much more risks in changes done by others
and not reviewed personally, based on the subjective trust on the other
developers.
IMO, we could have released JAMES 2.2.0 as V3. And the next release to ship
with the improved fast-fail should be 3.0.0, IMO, even though we have an
early version of that concept in 2.3.0. IMO, the migration to in-protocol
rejection from bounce notices is a major functional change.
I fear that we'll have different experimental version both in next-minor
and in next-major, and maybe we'll have a stable release of the fastfail
only later.
My fear is that if we numbered 2.2.0 as 3.0.0 then we would have
probably numbered 2.3.0 as 4.0.0 and next-major as 5.0.0: this seems to
me what M$ do and *not* what the major.minor.micro should incentivate us
to do.
I also think that we did a bigger change from 2.1.3 to 2.2.0 (broke
binary/source compatibility for mailets) and from 2.2.0 to 2.3.0 (broke
config.xml compatibility) than the change that will probably be include
in next-major so I don't like to do the big version step in this way.
Later we'll change the container or we'll remove the backward
compatibility for config.xml and this will need a major change again in
the numbers.. so it would be 3.0.0 for next-major, then 4.0.0 for the
following one.. we stop using the minor and micro numbers at all...
My preference is still to go with the 2.x.x until we're able to keep
backward compatibility for config.xml and storage.
The subjective nature of numbering a version should not be a problem, except
when when deciding (for example) which of multiple concurrent development
branches is going to have which release number.
--- Noel
I agree, I would have asked to solve this issue in a month, when I'll
probably make the proposal to branch next-major.
I would also like to have more concrete informations about your plans on
next-minor, if you still think you will work on it.
Stefano
