Joachim Draeger wrote:
Hi all,
Because something went wrong I think we need a cut and a complete restart of
discussion / collecting opinions. Because I suppose everything has already been
said, it should be possible to finish this part soon.
AFAIK there have only been mentioned three different possibilities:
1. Backport features from trunk to 2.3 branch (AKA next-minor)
- this includes only backporting and testing, a release may be done
very soon
As contributor I will not help with this.
I'm -1 on using the current 2.3 branch for this. If anyone want to start
this effort just create a new branch (copied from v2.3). "v2.3" branch
has to be there for 2.3.1 if needed.
As PMC member I would like to know what features are to be included in
this release before saying my last word about this "release". Generally
speaking I think it would be good to the project to have much more releases.
2. Create a config/storage compatible release from trunk (AKA next-major)
- To be able to start working on incompatible features, this may
imply branching soon
As contributor I don't care of this release. Nor do I as user.
As PMC member I think this the best compromise to put out a release soon
with new features and also make sure we test/consolidate a bit our trunk
(this will also help the next-greater release process).
I think we should branch as soon as possible because the work to keep
backward compatibility is really a lot and I'm (and others, I suppose)
already not working on many new features because they would break
compatibility.
Alternatively we could start working on incompatible things in
sandboxes/experimental branch, but I would prefer to work together on
the same folder (trunk): this give a better oversight on what is happening.
About features I think trunk is almost ready feature-wise for branching
(see the PROPOSAL Norman and I wrote almost a month ago for details). My
biggest concern is with handlerapi: I would like to include
handlerapi-v2, because otherwise we change that stuff once every
release, and I don't think this will be easy to understand for users.
3. Work on a non-compatible release from trunk (AKA next-greater)
- This could probably done without branching, or just branch when all
features are implemented. ETA is probably a bit later
As contributor this is my preferred option, but as PMC member I fear a
bit such an option.
I think we can break backward compatibility from time to time, but we
should avoid breaking compatibility in every single release. This means
that if we move to a backward incompatible release we should try to put
every incompatible change in, this time, and I think this would really
delay this release (I expect not less than 1 year). Otherwise I fear
that we would start making 3.0.0, 4.0.0, 5.0.0, every release backward
incompatible with the previous one.
I don't understand the "branching" issue: every release need a
consolidation branch, so I think this will need a branch as like the
next-minor and next-major. It is simply a matter of declaring we agree
on breaking backward compatibility and define an estimate date (range)
for branching.
Which kind of release do you prefer and why?
What are you willing to work on?
Does anyone have a completely different idea in mind?
I think that now that we are multiple active committers it is important
to talk not only of features but also of expected timelines, otherwise
we loose time. As contributor it is important to me to know if a branch
will happen in 2 months or in 6. This let me organize myself and
coordinate better with others.
Another option could be keep storage compatibility but remote config.xml
compatibility. Imho bidirectional (upgrade/downgrade) storage
compatibility is the most important to upgrading users and this would
allow us to stop loosing so much times on hacks/workarounds to keep
config.xml compatibility.
I think that a good plan could be trying to release next-major as
described above, then removing all the hacks to config.xml compatibility
and start introducing features that break config compatibility but not
storage compatibility (e.g: the mailboxmanager mapping feature ported to
all of our mailets and other components that access the repositories).
This would include possible container changes (osgi/spring experiments)
and more.
This would give us a couple of releases before the next-greater, and
hopefully a shorter release cycle than moving to a full-incompatible
release now.
Imho a good strategy could be to define a tentative release cycle and
define features we can include and type of releases based on dates.
Maybe something like: a release every 6 months (excluding mantenaince
releases). Then at every cycle we can discuss the type of release we
agree to work on (backward compatibility, features we plan to be able to
include, and so on). Maybe some times we'll be able to do only a minor
release, some other time we'll include much more features. As an example
we release 2.3.0 at the end of october. This mean we should try to
release the next one near the end of April 2007. Starting from this
point we could discuss what we plan to be able to do in the mean time,
what kind of features we expect to be able to work, if we think or not
to be able to consolidate our efforts for that date and so on. Of course
we cannot force dates, because bugs will delay the consolidation but we
can try to follow the plan at our best.
As a side note I'm not likely to work on conversion tools: it is really
boring to write such things. That's why I consider backward
compatibility an important issue in our planning.
To avoid an endless discussion I propose an end date that is hopefully the start
date of a new vote: Thursday 12/21/06
I guess some of us will be completely offline around Christmas / turn of the
year. Maybe you could give a hint whether you'll be able / want to participate
on
possible decisions.
I'll be here always.
Yes, I'm in a hurry because I think that too much time has already been lost and
this project needs to be more dynamic.
+1
I think "to be more dynamic" would be the best cure for james.
Joachim
Thank you for trying to fix this issue.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
