Addressing MC stagnation.
Leonard den Ottolander
leonard at den.ottolander.nl
Mon May 23 20:21:28 UTC 2005
Hi Jindrich, Miguel,
On Mon, 2005-05-23 at 12:28, Jindrich Novy wrote:
> On Sun, 2005-05-22 at 17:46 -0400, Miguel de Icaza wrote:
> > * Release-often: MC has not been officially released for a
> > long time. I propose that the current CVS gets released
> > as MC 5.0 and if any issues are found with the release
> > we release 5.0.1, 5.0.2 and so on to address these problems.
I don't see the point of doing a major version jump. Although a lot has
been fixed there hasn't been that much new code introduced to justify
this. 4.6.1 is fine with me. 5.0 would be more of a release number for
when we have full extended charset support and all libraries we depend
upon are up to date.
> Sounds good to me. What about releasing mc in a given time period to
> prevent a lingered release cycle? Releasing a new mc (with changing its
> middle release number for instance) two times per year, say 1st Jan and
> 1st June, would be good at least for the downstream maintainer's point
> of view.
I disagree with this as well ;) . I think the best way to go would be to
work out a road map and work towards the milestones. Although I can
understand why some projects use a periodic release schedule (like
Fedora where it is impossible to synchronize the release of all included
packages anyway) it feels very unnatural for a project like mc. We
should just try to set up the TODO in such a way that we can have a
release once or twice a year (or even more often, but based on a
roadmap, *not* a timetable).
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
More information about the mc-devel
mailing list