james-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [DISCUSSION] Release descriptions
Date Fri, 17 Nov 2006 17:28:37 GMT
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


Mime
View raw message