|
From: Ian L. <ian...@gm...> - 2007-09-25 13:32:17
|
Wouldn't managing scope and entering a testing phase and releasing final versions more often make more sense then? Do we really need ALL the features in 4.3final that have been added since 4.2 final? Couldn't a final release have been made already if the amount of features that were incorporated into each version was managed differently? I think that more than enough features have been added since 4.2 to have buckled down, tested and released a final version. Under the current system the final version is basically unusable since it's so old. It seems to me that finals should still have the same quality standards, it terms of testing but that a feature freeze or some way to control scope should be implemented to be allow final versions to be released more often. 2007/9/25, Vampire <Vam...@gm...>: > > > > Dale Anson schrieb: > +1 > > It seems to me that going with a 4.3.0, 4.3.1, etc, numbering scheme > would be better. Right now, it looks like the last "stable" version of > jEdit is from 2004, which just isn't true. > Yes, it is. The pre versions are pretty stable and quite usable if we > release them, but they don't deserve being called a stable final release. > > I suggest calling the current version stable, give it a number, and go > forward with the > major.minor.patch system. > > I don't want to list AGAIN the reasons not to do it. The current version > doesn't deserve being final, so why should we make it final? Just because > some people that are not happy with the numbering scheme, or because of the > fact that the last final release is long ago? Or because of people asking > when it comes out? I say NO, these are NOT the right reasons to call a > release final. It is done when it's done and not earlier. And as all jEdit > developers have only little spare time to work on it, it needs time. If > someone is not happy with this, he always can submit bugfixing patches and > maybe become a core developer later on to speed up the development. > > > Dale > > > Alan Ezust wrote: > > > When jEdit was a one-person development effort, Slava knew exactly > when it was "final" because he decided at that point to move on to the > next version, and had no plans to go back to the older one. > > Perhaps we should get rid of the words 'final' and 'pre' from our > version numbers entirely and just use decimal point notation? > > > > On 9/23/07, Kazutoshi Satoda <k_s...@f2...> wrote: > > > > Hi Slava, > > Some jEdit developers discussed about the next release which might be > 4.3final. In the discussion, I got a question about the term "final". > > Current sequence of releases (which I understood) is, some pre releases > (4.3preX), and the final release (4.3final) possibly followed by patch > releases (4.3.1, 4.3.2, ...). > > But then, I think the term "final" is just misleading. It is not the > final. I did misunderstand as if no patch releases will take place > after the "final" release (because 4.2final was so) before looking into > MiscUtilities.buildToVersion(). > > If it can be followed by some patch releases, I think "4.3.0" is more > natural and easy to understand because some large projects now use this > numbering (GCC, Apache, Subversion, OpenOffice.org, ...). > > If the term "final" had some special meaning or releasing policy, could > you please explain? > -- > k_satoda > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > -- Ian Lewis ian...@me... http://www.ianlewis.org/ http://jsxe.sourceforge.net |