Subject: [tryton] Re: Release strategy

From: udono <[email-masked]>
Date: Mon, 30 Jun 2008 01:09:21 -0700 (PDT)

Hello ced,

> On 19 Jun., 23:15, Cédric Krier <[email-masked]> wrote:> I think a good strategy for release is like OpenBSD.
> > It is based on fixed date release (2 per year).
> > I don't know if 2 releases per year is good.
One thing I forget. For this year and the first release version I
prefer to have one pre-release asap and in november/december a
bugfixed final release for the starting fiscal year 2009.

Greetings Udo
--~--~---------~--~----~------------~-------~--~----~
--
[email-masked] mailing list
-~----------~----~----~----~------~----~------~--~---

---

From: udono <[email-masked]>
Date: Sun, 29 Jun 2008 10:06:46 -0700 (PDT)

Hello ced.

On 19 Jun., 23:15, Cédric Krier <[email-masked]> wrote:
> I think a good strategy for release is like OpenBSD.
It depends on serveral things:
- How many developer we are.
- How we define a release?
- Are there in-between releases for Bugfixing?
- Give we promises to the users like a migration promise for each
release to another?
But I think you are right, two major releases are quite enough for the
first.

> To be able to have fixed date release, we need a strategy to stabilize
> the software for the date. So I propose something like that:
> - We stop the development on the framework at a date pre-defined
>   (depending of the release date). So we create a branch of the current
>   tips.
I would suggest one release in the 4th quarter of the year and one in
the summer (2.quarter) that the release is ready for new a fiscal
year, which started often on 1. January or 1. June.

> - All leaders of each modules must take care that his module works correctly with the
>   fixed framework. Once a module is working, we create a branch for this
>   one. And we fixed a deadline to have all the modules working otherwize
>   others can take the leadership of the module.
Yes, this is a good step. But I would suggest to make cross-testing
each others module. Than we are double secure against the developers
blind spot.

>   We must also check that the documentation is always up-to-date.
Yes this will be soon very important, but not for the first release.
Documentation content is general a community job for my opinion.

> - When a module is branches, the translations teams can start to fix the
>   translation.
Ok, this is possible, but not necessary for me. Translation could be
done easily 'by the way'. But you are right, the translations need a
final overview and check.

> - When each modules are branched, we start creating release candidate
>   and ask the community to test it.
> - At the date, normally all is working :-) and we can make the release.
Yes, this looks like a good release cycle for my opinion.

Greetings Udo

---

From: Cédric Krier <[email-masked]>
Date: Thu, 19 Jun 2008 23:15:46 +0200

-- 
Cédric Krier