On 17 Feb 2007, at 16:05, Guenther Noack wrote:
If I understand it correctly, the policy with those versions is that
subproject maintainers who consider their subprojects stable can copy
them into /stable/.
I think this is sensible. Stable should be considered a 'works for
me' branch; once you aren't having problems with your code, let other
people try to break it.
When something is supposed to be moved into
/releases/, it should be approved by Quentin and Nicolas then? Is that
right?
I would imagine that releases would be done by freezing the stable
version for (say) a month. During this period, nothing other than
bug fixes can be committed to /stable (new features can still go in /
trunk). Once this period is complete, /stable is copied to /release/
version, and frozen (unless anyone feels like back-porting fixes
from /stable), and /stable is then open to commits of new features.
We can still put things in releases (particularly 0.x releases) that
are not stable, as long as the documentation clearly marks them as
experimental, and they are not part of the core system (for example,
new applications or components could be put in a release, but it
should be made clear that people shouldn't expect them to work
properly[1]).
I think the flow of things from /trunk to /stable should be fairly
fluid; when something seems to work, throw it in /stable and let
people break it. Flow from /stable to /release should be far more
rigid, and should only happen just prior to a new release. For each
release, we should select a release team who have the final say on
what is allowed in and what isn't. In my experience this is one of
the least fun jobs in an open source project, so nominate Quentin and
Nicolas :)
David
[1] Possibly, we should have an NSApplication+experimental category,
which will pop up a warning whenever an experimental application is
launched that was compiled with this category?
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
