Ralph Goers pisze: > My numbering has nothing to do with yours... > > 1. The versioning manifest described in [1] used to be at > http://cocoon.apache.org/versioning.html. Somewhere along the line that > page was apparently removed. Probably because it wasn't being followed. > There was a followup thread a while later where many committers didn't > even remember we had passed this.
It's probably a good time to get back to this. In my view it's is quite easy to follow versioning guidelines provided two conditions are fulfilled: a) We really release more often so people don't have to wait too long to see their changes in a released version b) We are less reluctant on increasing major and minor versions. c) We are less reluctant on deprecating old stuff. We are already quite old project and we are moving so it's natural that there is some stuff to deprecate. Also, as we are adopting new paradigms replacing old ones it is quite expected that some back-incompatibilities will appear. We have to live with that I think. Honestly speaking, for me, point c) is the most painful one. Sometimes I really lost any of my motivation to create some new exciting stuff only because I fear somebody will chime in somewhere in the thread saying: "I don't like it because it's not 100% back-compatible, it cannot replace our old, scaring code." I'm sure that I'm not alone with these feelings and I'm sure this subject will reappear very, very soon due to someone other than me. > 2. Personally I think 2.2 should be 3.0, but that is just me. Because of > that I have no real problem breaking binary compatibility with it and so > I definitely don't have a problem with what you are proposing there. Yep, I agree that current 2.2 should be better numbered as 3.0 but we could discuss about it two years ago, not know. Or we can discuss about it when planning next releases to not repeat our own mistakes. > 3. Welcome to the club. We've all been depressed at one time or another > over how infrequently we do releases. But the list of issues shouldn't > end there. For one, your original fix shouldn't have been able to go in > without causing the build to test. The number of unit tests we have is > abysmal. We can drastically improve this in 2.2 since maven makes it so > easy to build and run them, but I don't think it is that hard in 2.1 > either. I don't know 2.1.x branch as good as trunk but my personal impression is that we have already much more improved situation in trunk when it comes to unit testing. Speaking about myself, I always try to commit any non-trivial stuff well-covered by unit tests, especially if it's new functionality that I'm sure how tests should look like. You can see latest effort of me and Joerg to enable tests that were disabled long time ago for various reasons. Moreover, we have working continuum instance that always guards us from broken tests. You can like me or not for that but I will always ask for tests, especially if you touch new stuff that has highest priority for me. -- Grzegorz Kossakowski
