openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

Le 09/02/11 09:48, Nicolas Bessi a écrit :
> Hello,
>
> I did not see that release date of 6.1 was already set for april, my fault. So we will have important release every 4~6 month that is a faster release cycle as it was discussed with the community.
> There is still a lack of communication of what should be done in each milestone even if feedback.openerp.com is a good starting point.


Actually you're right, we have not yet explained the future release 
cycles. We'll try to publish an official description soon, but here are 
some starting points:

- A release labelled 6.1 is not a minor release, it can perfectly well 
introduce important changes. The numbering is perhaps more related to 
the amount of changes and the time elapsed since the previous release. 
Maybe we should introduce version numbering a la Ubuntu, to reflect this.
- Every new release can introduce important changes, but we try to keep 
the framework backwards-compatible as much as possible with the previous 
release.
- BUT, we don't know yet if 6.1 will really be released in April, 
because many community members are afraid of too frequent releases like 
this.
- However, even if 6.1 is released later, we will try to keep the trunk 
production-ready all the time (thanks to YAML test suite and new dev 
processes), so that early-adopters can in fact follow the trunk closely.



> I think it is good point to feet fixed guideline, but it will be an import effort to provide for partner till the end of april (6.0 stabilization and following trunk improvement make a lot of work) .
> I'm also a little bit afraid to have non retro-compatible features in every release will make a lot of branches to manage.


Back to the current topic: as you can see in the introduction email this 
changes has been designed with a backwards-compatibility mechanism that 
makes it possible to have old and code living next to each other, and 
this is only in trunk of course, not in 6.0.

We certainly do not expect the community to start adapting their code 
now to this new scheme. However it makes a lot of sense for us to 
introduce this kind of change as early as possible in the 6.1-trunk, 
because it could still break many things, and needs to be tested as much 
as possible before 6.1 is released.



> > Such modification should be planned and announce at lesat 2 or three month in advance.


Certainly, and really, this is what Thu was doing with this thread: 
introducing this change to the community, even though it will only 
become relevant for you in a few months at the very least, when you 
start looking at 6.1.

We are working hard with partners and community to make the 6.0 rollout 
go as smoothly as possible, but development for 6.1 had to start too if 
we don't want to have to wait 2 years for the next release...

I hope this helps clarify the context of this change...