Niclas Hedhman wrote:

ODD MINOR = development in progress.
EVEN MINOR = released versions.

Sounds unsurprisingly linux like.....

Actually, I would like the odd/even to be the opposite, but since many people knows of and understand Linux approach, I don't want to introduce any confusion.

:) Understood.


Question on minor/major version increments. It is quite likely that the
code between a 3.2 and a 3.3 will be very different.

Actually not. When Release 3.2 is made, the 3.3 starts at 3.3.0 in the next build. BUT during the 3.3 evolution there could be bigger changes, and if the day comes when/if there is an incompatible change the 3.3.N is bumped to 3.9.0 and the incompatibilites would lead to a 4.0 release later.

But would you do that for something where the contracts to the externel entities are still respected (i.e. it is compatible), but a particular feature was rewritten/refactored significantly?

One thing the Cocoon
folks do between their minor version increments is "branch" the dev stream.
(Actually they have a completely new repository, but if we go SVN, the
branch would probably make most sense--they have always had problems with a
true branch in CVS).

What does the branch buy us? In effect nothing regarding the management of development releases, since we are still fighting with actual versioned artifacts that can be identified by Maven. So, during the development branch, there is a need to keep versioning the "builds" and have all the pieces of the system to understand the scheme you are deciding to use.

I was just throwing it out there. Between minor number builds, Cocoon does change or refactor the internals a bit while still respecting the old contracts. There was work to help keep the "production" system free from bugs while new features made it into the new version. I am not saying we should do it just because they do, or that it necessarily makes sense for us. I am tossing it out there to find out if it does make sense for us. Duck if it doesn't apply.

To keep it straight, would we adopt such a practice here?  That way we can
easily keep up the "production" build with any bug fixes so that it remains
as stable as possible, while any new work happens in the dev stream.  That
would truly be linux like.

How are you suggesting that we 'label' the pre-3.4 development builds and store them in Maven repos, understood by various system coming in contact with them.

?


I guess I am not understanding the question.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to