cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject [RT] Versions
Date Tue, 20 Apr 2004 08:45:24 GMT
In [1] I suggested that we continue the development of 2.1.x and port
some nice things from the 2.2 branch back as long as they don't create
big incompatibilities. 
Now, I started to port back the new environment handling and found out
that it's not that easy :)

In the current 2.2 branch we did the following changes at once:
a) update container to fortress
b) change the tree processor
c) remove deprecated code
d) update the environment handling

We did a) and b) to have a better base for the blocks implementation. As
we now follow a different road, these changes are currently not important
for 2.1.x.
Unfortunately, a clean solution for d) depends on c) which means: 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.

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.

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.

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! So, in fact using
version numbers is a bad idea :) Simply numbering them would be better
(1, 2, 3, ... 1004 etc.)

I think, Stefano mentioned some months ago that the biggest mistake
when starting with the development of Cocoon 2 was the version
change from 1.x to 2.0 and the completly different architecture in 2.0.
So, users couldn't simply update but had to rewrite their app. A
smooth transition would have been better. (I hope my memory is right,
Stefano, I don't want to lay words in your mouth).

Anyways, I totally agree that a smooth transition is a good idea. If we
look at the changes we already did for 2.2, it would have been better
to do them in different steps. This makes development easier and it
makes updating for users easier.

My opinion is that we should remove deprecated classes (some of them)
in our 2.1.x branch *now* in order to create a smooth transition and
to build a better basis for the future development.
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.
We clearly indicate that although we have a major version change,
there are only minor incompatibilities that shouldn't affect users.
Actually this is the hard part! We have to convince users that although
it's a major version change, there shouldn't be a difference between
updating to a fictional 2.1.5 or 2.2. We - as the developers - take
care of this fact. We could create the "Cocoon Version Manifesto".

Removing deprecated code is imho important for users and developers. Of
course, for us developers it makes life easier as it makes
innovations easier and as you don't have to care about some nasty things
anymore. But although users benefit from this as they can use
new features (they are slightly forced to use them :) ). And in addition,
in some cases the support of deprecated interfaces is not done in
a nice way, so deprecated code might not run that smooth and fast
as the non deprecated versions.

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.

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




Carsten Ziegeler 
Open Source Group, S&N AG

View raw message