Proposal for the development cycle

[Farzad Sehat]

2009/11/13 Xavier Oswald <xoswald at gmail.com>

> On 15:32 Fri 13 Nov     , Mildred Ki'Lya wrote:
> > Hi,
> >
> > (french at the end)
> >
> > It has been some time that I was thinking about this, and I think I
> > should put it here for debate.
> >
> > The problem: in the past, we spent too much time between releases.
> >
> > A solution:
> >
> > I think we should agree to make releases regularly, regardless of
> > whenever we added many new features or not. The idea is that every 6
> > month (Halloween and May Day, that seem to be popular) we would start to
> > make a release.
> >
> > I thought that if we agreed to this we would need two branches, at least
> > before the release. One would be frozen to prepare it for the release,
> > only accepting bugfixes. The other would continue to accept approved
> > features and would merge with the first to get the bugfixes as well.
>
> Doing two branches or such is useful for larger community than our.
>
> What I think is:
>
>  * if we do a release twice a year, we should freeze stable 1 month before
> the
>   release. The point here is if do this choice , 1 month is not enough
>   for having something of good quality. But for a each 6 months release, we
>   cannot avoid more than 1 month for freeze.
>
>  * Im more favorable of releasing each year and having 2 or 3 months of
> freeze
>    for the stable branch.
>
> We have to keep in mind that releasing is not only working on the compiler.
> Website has to be updated, announcement have to be done, and the biggest
> thing
> is that we need to update the documentation too. If we release each 6
> months Im
> afraid of the lack of manpower to be able to do such a thing. We are only
> few
> people working around Lisaac and for me, it seems fair to release each year
> for
> the quality of the project.
>
> I absolutely agree with this point of view, our community is not big enough
and moreover
there is a lot of work to be done in the documentation. 2 release per year
is too much and
we have to favour quality.
As Xavier said we have to freeze the stable 2 or 3 month before release in
order to have a high
quality release.
The key feature is to make regular and complete report to benoit about the
feature each member is developping.
This way benoit can merge them more easely and more efficiently to the
master branch and moreover he can merge
to the stable branch more often. Indeed a good communication about all
developping features let Ben to work
better and to have fewer bug when freezing the stable.


>
> What could be fun is that we freeze stable the 1st October and we release
> the
> 15th December. So people will have a new release of Lisaac to play with
> during
> christmas (when people have more time than during the year).
> And It will be the Christmas Gift to the community and people playing with
> Lisaac ;)
>
>
Hey Santa Claus what's my present ?
A brand new Lisaac realase, my son.
;)


> > But we can also keep only one branch (stable). stable would be frozen
> > for features before the release, and new features would be kept in
> > separate branches (one branch per feature).
>
> That the right way for now I think.
>
> Greetings,
> --
>  ,''`.| ====== Xavier Oswald  ====== | mail: xoswald at debian.org         |
> : :' :| Engineer at CALDERA GRAPHICS | http://www.caldera.eu            |
> `. `' | GNU/LINUX Debian Developer   | http://debian.org                |
>  `-  | Isaac Project Developer      | http://isaacproject.u-strasbg.fr |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkr9gHUACgkQpDDGqoi7tR5mNQCdGNb2rPdJbPvOnWzgE8Rh4dXQ
> 8WoAnizD32XkN/Jyz0JOoZAv4objOmjf
> =oPtZ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Lisaac-devel mailing list
> Lisaac-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/lisaac-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20091113/57952e6d/attachment.htm>