Baruch Even <[EMAIL PROTECTED]> writes:
| I believe it would be better if we had a numbering scheme like the linux
| kernel, with a development series and "stable" series, where every
| now and
But this is excatly what we want to avoid. We want stable releases
often not an ongoing development branch that goes on for a long time.
| then a backport of features and fixes will be done to the stable series,
| and when the time is ripe the devel series will be version jumped
| and
Backports of new features should be kept to an _absolute_ minimum!
(preffereably not at all)
| The benefit I see is from the "marketing" side, this way we will have a
| stable version that gets at least some of the new features and the needed
| fixes without it being considered a development version. There are places
| (notably the university where I learn) that their tech staff will not
| install something unless its dubbed stable, it can be from micrsoft
1.1.5 is dubbed stable, if the documenttaion does not reflect this,
fix the documentation.
| (notably unstable) but if its a release version they will consider
| installing it, otherwise they will just say no.
|
| The current installed version of lyx is 1.0.4 on their systems since thats
| the last one they saw dubbed stable. Everything else they recognize as
| development and will not install. This means for example that the lyx
| 1.1.5 with hebrew support will not be installed since they fear its
| development version.
documentation problem then.
| This will not only help me, I'm pretty sure there are many other places
| where they won't install something that is officially marked as a release
| version. It is a problem to see a program with version 1.1.4fix3, one may
| consider if its development team is so incapable so as to need three
| consequtive "urgent" fixes.
I won't listen to this kind of argumentation. Would it be better if we
just kept the 1.1.4 version number and silently released new ones with
fixes.
would 1.1.4.3 be better?
| In the proposed method we will simply have
| 1.2.x for the the stable and 1.3.x for the development, with backports to
| update the older version, the transition will be to rename 1.1.6 to 1.2.0
| when the time comes for its release and the new devel version will be
| 1.3.0.
You need to read a bit in the old mail-archive.
(short: we used to do it like this...gave us too long development
cycles)
Lgb
