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
