Solution #2:
Create a rotating release schedule
For example:
6 month
6 month
12 month
6 month
6 month
12 month
etc
This way you can upgrade upstream software and fix bugs in the shorter cycles and have time to fully bake in new features in the longer cycles. You would never be more than 1 year away from the start of the longer cycle and would never get out of date thanks to the short cycles.
For example:
6 month
6 month
12 month
6 month
6 month
12 month
etc
This way you can upgrade upstream software and fix bugs in the shorter cycles and have time to fully bake in new features in the longer cycles. You would never be more than 1 year away from the start of the longer cycle and would never get out of date thanks to the short cycles.
Solution #3:
Officially start work on next LTS version when previous LTS version released
Written by
Aielyn the 18 Sep 09 at 01:59.
Right now, to my knowledge, LTS versions are simply the version that is released in April of even-numbered years, and simply get marked with "LTS" to indicate continued support.
I suggest this be altered. Rather than simply making a new version every 6 months, have two separate tracks: one track, based on the most recent LTS, would be upgraded every six months. The other track would be a more significant upgrade, and would be developed over the period of two years with a focus on innovation rather than simple evolution.
Obviously, improvements in the normal upgrades would find their way into the LTS upgrade if applicable, but this would give Ubuntu developers 2 whole years to make major changes where appropriate, and to get all packages up to scratch for such changes.
Alternatively, have the LTS version be the final one before the major upgrade, as it's the best version of that particular set. So, in this context, the next "major upgrade" would be 10.10, as the next LTS version is set for 10.4 (to my knowledge).
Right now, to my knowledge, LTS versions are simply the version that is released in April of even-numbered years, and simply get marked with "LTS" to indicate continued support.
I suggest this be altered. Rather than simply making a new version every 6 months, have two separate tracks: one track, based on the most recent LTS, would be upgraded every six months. The other track would be a more significant upgrade, and would be developed over the period of two years with a focus on innovation rather than simple evolution.
Obviously, improvements in the normal upgrades would find their way into the LTS upgrade if applicable, but this would give Ubuntu developers 2 whole years to make major changes where appropriate, and to get all packages up to scratch for such changes.
Alternatively, have the LTS version be the final one before the major upgrade, as it's the best version of that particular set. So, in this context, the next "major upgrade" would be 10.10, as the next LTS version is set for 10.4 (to my knowledge).
Solution #4:
Increase the release cycle to 1 year and give rolling upgrades/updates
Ubuntu devs are really hard pressed for time to introduce new features into the next release. Also, despite their hard work, there still definitely be a list of bugs that remain simply because they ran out of time to get them fixed :-(. The poor devs also only get around 1 month just to define the new features that will be introduces, and as they have so little time to put all of those cool ideas out there into Ubuntu, only so much is put into the next release. More time needs to be devoted to a release of Ubuntu so that it is more polished and has more bugs fixed up, as well as other compatibility fixes that could be introduced into the release.
Sure, the idea of an LTS should remain, and should probably remain at once every three years, but each release should have more quality put into them, and also ensure that the "if it ain't broken, don't fix it" philosophy is implemented, because there are some things that work well in previous releases that don't work well in other releases.
At the end of the day, all I am saying is that Ubuntu releases should be released yearly instead of 6-monthly, so as to allow for a higher-quality release, and updates/upgrades, especially for those in terms of aesthetics and the whole look of the OS should continue to roll across the year that the release is current.
Just my tuppenceworth for this idea ;-)
Ubuntu devs are really hard pressed for time to introduce new features into the next release. Also, despite their hard work, there still definitely be a list of bugs that remain simply because they ran out of time to get them fixed :-(. The poor devs also only get around 1 month just to define the new features that will be introduces, and as they have so little time to put all of those cool ideas out there into Ubuntu, only so much is put into the next release. More time needs to be devoted to a release of Ubuntu so that it is more polished and has more bugs fixed up, as well as other compatibility fixes that could be introduced into the release.
Sure, the idea of an LTS should remain, and should probably remain at once every three years, but each release should have more quality put into them, and also ensure that the "if it ain't broken, don't fix it" philosophy is implemented, because there are some things that work well in previous releases that don't work well in other releases.
At the end of the day, all I am saying is that Ubuntu releases should be released yearly instead of 6-monthly, so as to allow for a higher-quality release, and updates/upgrades, especially for those in terms of aesthetics and the whole look of the OS should continue to roll across the year that the release is current.
Just my tuppenceworth for this idea ;-)
Solution #5:
One year release schedules with 6 months beta/RC testing.
Written by
jjchico the 10 Feb 10 at 11:15.
(See related
idea #23624 )
Planning should be like this:
* After a new release (Ubuntu X), X+1 develops in a similar way it is done now.
* About 4 months after release there is a (maybe soft) feature freeze and alpha cycles start. Developers and more advanced users start using alphas everyday.
* About 6-8 months after release, first beta is published. Developing concentrates in release bugs. Experienced users start using betas everyday.
* About 8-10 months after release, first RC candidate is published. Normal users that want to test the new system are encouraged to update to the RC and report bugs. There is time to solve important bugs before final release.
During beta and RC cycles, core developers con start the basis of the next release (X+2) so the overall progress of the distribution do not need to be affected, specially when you do not need to produce a release every 6 months.
(See related idea #23624)
Planning should be like this:
* After a new release (Ubuntu X), X+1 develops in a similar way it is done now.
* About 4 months after release there is a (maybe soft) feature freeze and alpha cycles start. Developers and more advanced users start using alphas everyday.
* About 6-8 months after release, first beta is published. Developing concentrates in release bugs. Experienced users start using betas everyday.
* About 8-10 months after release, first RC candidate is published. Normal users that want to test the new system are encouraged to update to the RC and report bugs. There is time to solve important bugs before final release.
During beta and RC cycles, core developers con start the basis of the next release (X+2) so the overall progress of the distribution do not need to be affected, specially when you do not need to produce a release every 6 months.
Solution #6:
Green light alert status
Written by
madhi19 the 11 Apr 10 at 10:42.
What I propose is a Green and Yellow light alert status system based on a weekly poll on the Ubuntu forum in the month or so that follow a final release. The moderators and canonical could also issue an emergency Red light at any moment to warn off users of a major problem with a release. It could also be integrated with the gnome notification system and the update manager so that even users who don't visit the forum learn about the alert status.
What I propose is a Green and Yellow light alert status system based on a weekly poll on the Ubuntu forum in the month or so that follow a final release. The moderators and canonical could also issue an emergency Red light at any moment to warn off users of a major problem with a release. It could also be integrated with the gnome notification system and the update manager so that even users who don't visit the forum learn about the alert status.
Solution #7:
Turn one of releases in a "Service Pack" release
In order to increase the stability of the releases of Ubuntu and reduce the number of ongoing releases, one of the releases that happen each year (for instance, the october release) could be turned into a kind of "Service Pack" release. This is, the focus on the development from April to October would be on fixing bugs and making a more stable and fast operating system.
In order to increase the stability of the releases of Ubuntu and reduce the number of ongoing releases, one of the releases that happen each year (for instance, the october release) could be turned into a kind of "Service Pack" release. This is, the focus on the development from April to October would be on fixing bugs and making a more stable and fast operating system.
Solution #8:
Beta upgrade option to help find and resolve problems
Written by
turbolad the 6 Nov 10 at 23:37.
Between LTS releases once a year in April, testing of the next LTS could be taking place during its development.
Between October and the LTS release in April, the "normal" release should be a beta release, so users who wish to beta test it can upgrade to it in October and give it 6 months of thorough testing ready for the next LTS release derived from it.
This would encourage more users to beta test, instead of downloading a beta version of Ubuntu and installing it.
Between LTS releases once a year in April, testing of the next LTS could be taking place during its development.
Between October and the LTS release in April, the "normal" release should be a beta release, so users who wish to beta test it can upgrade to it in October and give it 6 months of thorough testing ready for the next LTS release derived from it.
This would encourage more users to beta test, instead of downloading a beta version of Ubuntu and installing it.
Solution #9:
A once in year release date
Written by
DeMus the 22 Oct 11 at 09:37.
Every time Ubuntu brings out a new release it is filled with bugs which will be dealt with in the first months after the release date. Since the releases appear every 6 months, it means about half of the 6 months people have a buggy system. This can't be good.
Another thing is that by doing it this way, the developers are working on 5 releases at the same time: 1 new one which will be released in a few months and 5 old ones which have to be maintained.
When the six months are extended to 1 year developers have more time to finish and test the new version. Quality will therefore be much higher.
Support time should be 1-1/2 years for those versions released in an odd year and 2 years for those released in an even year. (kind of LTS version)
This way developers are working on 3 versions max, which give them more time to really maintain them.
Every time Ubuntu brings out a new release it is filled with bugs which will be dealt with in the first months after the release date. Since the releases appear every 6 months, it means about half of the 6 months people have a buggy system. This can't be good.
Another thing is that by doing it this way, the developers are working on 5 releases at the same time: 1 new one which will be released in a few months and 5 old ones which have to be maintained.
When the six months are extended to 1 year developers have more time to finish and test the new version. Quality will therefore be much higher.
Support time should be 1-1/2 years for those versions released in an odd year and 2 years for those released in an even year. (kind of LTS version)
This way developers are working on 3 versions max, which give them more time to really maintain them.
Propose your solution
Attachments
No attachments.
Duplicates
Comments
neon
wrote on the 5 Nov 08 at 07:16
hint: huge blocks of text are not attractive. use paragraph breaks. ;) it makes things easier to read.
jjchico
wrote on the 5 Nov 08 at 10:12
You are somehow right but things in the Linux world are different to Windows or Macs. Linux is still evolving very fast in every aspect: libraries, applications, GNOME, KDE, ...
If you want stability for long periods, then LTS releases may be for you.
I concur with the first commenter.
My opinion, based solely on the title (since the description is unreadable) is that this idea is a dupe.
Post your comment