On 2/17/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote:
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.
yep, that's how I understand it too.
> > 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]).
good idea. And yes, a freez for a month before a realease makes sense.
> 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 :)
That's indeed how I understood it :-) but thanks for volunteering us to the job :-P
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.
Very good point.
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.
Yes, perfect summary.
I will post another email regarding which frameworks goes to stable next week. I guess that would raise more discussion.
OK.
> [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?
Good idea too ! -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
