On 2/17/07, David Chisnall <[EMAIL PROTECTED]> wrote:
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 :)
I agree with David.
As for targeting GNUstep stable release,
I would say it is impossible for GUI application.
We often find GNUstep bugs when writing applications and report it.
Then it get fixed in GNUstep svn.
Therefore, the applications has to work with GNUstep svn version.
So my proposal is that -stable work against GNUstep /trunk,
and -release work against GNUstep stable.
Whenever GNUstep make a release,
that is a good time for us to make a release, too,
or probably 1-2 months later to focus on bugs.
A summary so far is:
1. -trunk: developers' playground
2. -stable: 'works for me' version, targeting GNUstep svn, target of
bug reports.
3. -release: 'works for everyone' version, targeting GNUstep stable.
I will post another email regarding which frameworks goes to stable next week.
I guess that would raise more discussion.
Yen-Ju
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
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
