cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [RT] Versions
Date Tue, 20 Apr 2004 09:31:29 GMT
Carsten Ziegeler <cziegeler <at> s-und-n.de> writes:

> WDYT?

Hmm, sorry, but that's to much confusion IMO. But read on ...

<snip what="changes 2.1 => 2.2"/>

> only
> if we remove deprecated code, the environment handling can be
> improved. Or in other words: backporting to 2.1.x would require to remove
> deprecated classes which could really affect users.

What does "remove deprecated classes" mean? I guess only the usage of them or
not? The classes itself can stay where they are (or moved to src/deprecated or
whatever).

> So, I think it's time to think a little bit about versions:
> 
> It seems that the general understanding of versions is that a minor
> version change (e.g. from 2.1.4 to 2.1.5) is always compatible and
> that users in many cases update if a new minor version is released.

Yes, this is also my impression from reading the users list. But we are not
always completely compatible, so there are often some minor issues.

> A major version change (e.g. from 2.1.x to 2.2) might contain
> incompatibilities and it seems that users are reluctant to update.

That's naturally I think.

> Following this logic, it would mean that if we would rename the current
> 2.1.x version that we have in the CVS to 2.2, users would not update
> just because of the version name and not the content!

IMO we should just make clear that the 2.1 => 2.2 upgrade is not that major than
2.0 => 2.1. But that's only true if we release the first version of 2.2 short
after the fork from 2.1.

On the other hand I didn't get the feeling that there were many problems when
upgrading from 2.0 to 2.1. This might be due to not upgrading at all of course.
Probably users start a project with a specific Cocoon version/the latest release
at this time. During the project they do only the minor upgrades. When starting
the next project they use the latest available version at that time again. So
upgrade problems might be only rarely reported.

> So, in fact using
> version numbers is a bad idea :) Simply numbering them would be better
> (1, 2, 3, ... 1004 etc.)

I don't think so. The hierarchy versioning helps in deciding whether to do an
upgrade or not.

> Anyways, I totally agree that a smooth transition is a good idea.

I don't agree here. Maybe users would not upgrade at all because they fear there
are more incompatibilities with every minor release.

I also do not see a problem when users do not upgrade from one major to another
major version during a project's time.

> To indicate this, we should update the version number to 2.2 *now* in
> the cocoon-2.1 repository. This would mean that the next Cocoon
> version would be 2.2. If the need for a 2.1.5 arises we could still
> make a branch.

Now the confusion starts. IMO we should have clear version/repository matchings. 

> Removing deprecated code is imho important for users and developers.

+1 in general of course.

> We use the current cocoon-2.2 cvs as a scratchpad/sandbox to continue
> the blocks development. And if blocks are working, we decide which 
> version number to use (2.5/3.0/4.0 whatever).
> Each time we feel that a major version change is required we simply 
> do it in the cocoon-2.1 repository. If required, we can make a branch
> at any time. The main idea here is that we only have one repository
> with the HEAD. Only if required/requested we create a support branch.
> 
> Of course, if we follow this road, our repositories would have wrong
> names, but this imho doesn't really matter and we could rename the
> cocoon-2.2 repository without any problems.

I don't agree. This naming issue really matters. It's IMO much more important
than non-upgrades during project's lifetime. If we follow the proposal the above
cries for a cocoon-2 repository (the current 2.1) to make this at least clear.
And each branch is moved into a new repository. But not not the stuff is
branched out, but only the old one. This would make it consistent with the
current cocoon-2.0 and make an upgrade easier for people living from CVS. This
also means a 2.2 release would result in a cocoon-2.1 repository as quasi-branch
point.

> And in addition, 2.2 would be the first release with the official
> cocoon forms version. This alone makes a version change acceptable.

+1 you need valueable additionals/features.

Joerg


Mime
View raw message