cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: JXPathHelper
Date Fri, 28 Dec 2007 13:41:56 GMT
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

Mime
View raw message