27 Sep
2009
27 Sep
'09
9:30 a.m.
On Sep 27, 2009, at 5:57 AM, Sergiu Dumitriu wrote:
The choice of 2 branches precedes this proposal. In addition this
proposal to stabilize is not forever. It's limited in time.
We already have changes in trunk so it's going to be a bit difficult
maybe to remove the branch. If you have some idea to make it less
painful they are very welcome (even using git is an idea but someone
would need to setup a git svn mirror ad provide some explanations ;)).
Thanks
-Vincent
Vincent Massol wrote:
The point is to act as a team. We would all prefer to work on
innovation but:
1) it's not quite fair that some of us do while others are fixing bugs
2) we really have a huge backlogs of known bugs and small needed
improvements and we need a way to reduce them for 2.0.1
That said, this is only a proposal and everyone is free to work on
whatever he wants so yes I agree with your remark too. There's no hard
forbidding, it's just a recommendation that is there purely to try to
stabilize what we have, as a team.
Hi devs,
I'd like to propose a stabilisation operation starting now and for 1
month (ie from now to the 1st of November)
The idea would be that **no new feature** is allowed to be committed
in SVN.
I don't quite agree with this. Yes, we should concentrate on
stabilizing
existing code, but let's not block innovation. Also, is a new feature that participates to the
stabilization
allowed or
not? Like, the create color theme wizard from the incubator is a new
feature, compared to the current trunk, but it is a key element of the
Colibri skin.
Whatever has to go in 2.0.1 is ok.
In this case I'd say it's ok since I think we'd want this in 2.0.1
since what we have now is a bit too basic.
We have
several domains to stabilize quickly after the 2.0 release:
- Colibri skin
- WYSIWYG editor
- Rendering
- XAR 2.0
- conversion to 2.0 syntax.
- internationalization texts
- Various (office importer page shouldn't be displayed when the
office
server is not running, wiki macro textarea should be larger, etc)
These should go in both the trunk (2.1) and for 2.0.x
If there would be no new features, why have two branches?
> I also propose to release a 2.0.1 in 2 weeks time (i.e. for the 12th
> of October) and to continue 2.0.x release every 2 weeks till we reach
> that month's end.
>
> WDYT?