Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage.
I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is).
+1
Then one repository for testing new stuff, like the new block system - this will be the sandbox or scratchpad repository.
+1
And finally - as we already have - the site repository.
+1
As recently reported we already have incompatible changes from 2.1.4
to 2.1.5 (which we accepted to have!) and as I pointed out lately
I want to remove some deprecated stuff to continue the development
of the current version. And we have some major changes, like the Cocoon forms that justify a minor version changes anyway.
So, I think, we should: - tag the current cvs in order to create a branch if required
Isn't the 2.1.4 release tag enough?
- change the version to 2.2, so this will be our next release
+1
- try to follow the versioning guide (which is a work-in-progress)
+1
- move to subversion whenever we want
+1
- if the need for a 2.1.5 release arises we create a branch, revert the incompatible changes and use the branch
Doing it from the 2.1.4 release tag we do not even need to revert incompatible changes.
Joerg
