Reinhard Poetz pisze:
Daniel Fagerstrom wrote:
If you feel that you can spend some time on the 2.2 release without
endangering your GSoC task, feel free to do that. If not, focus on
your GSoC task.
Although I think that a C22 release would be more than necessary, I have
to agree with Daniel. It's not only you who currently has a more
important goal (GSoC) but others have too - otherwise the release would
be out for months. So don't worry too much.
At the end of August Daniel will evaluate your GSoC work. If you push
forward the final release or the documentation it will be great for the
project in general but (as you certainly know) doesn't have any
relevance for your GSoC evaluation.
I can agree with you both, but you have missed the point, IMHO.
I wanted to work on C2.2 release because current state of things effectively
stops me from continuing my work. We have already released RC1
so I think that major changes (even internal) should not come into 2.2 final.
Moreover, I'm almost sure that my work will destabilize trunk
from time to time because I've already learned that it's impossible (or,
ineffective in a case if you wait for perfection before committing)
to keep everything stable and working. This could lead to the situation that we want to
release 2.2 but my stuff is "half-baked" and since
it is in the core it stops the release.
On the other hand, I cannot (and wouldn't want to) release 2.2 only myself so
even there are folks willing to help whole process demands
some time and it cannot be speeded up by my full commitment. Thus I think the
quickest and most effective solution is:
1. Revert changes in r559394 that broke the trunk
2. Branch whole trunk for my GSoC work and start work there
While considering second step I'm starting to think that it would more make sense to branch modules that we are going to release so they can
stabilize and others could continue work in the trunk. What worries me is that our modules are not self-contained (they need parent poms,
for example) so I don't have an idea how to branch a subset of our modules. Branching whole trunk does not make sense because some modules
are ready for a release and some are not. Do you have an idea how to manage two versioning (maintenance and developer's) lines of our Maven
modules?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
