Debian User Forums

I was thinthing about that scenario in which, debian testing becomes Stretch (last stable),and testing line in sources.list jumps to new testing version.

So we're suppose eventually to change the testing reference line in source.list to the codename or the stable tag, before we come into the new testing version with a transiction upgrade.
Is there any transtion upgrade or we need to commit dist-upgrade command to jump to the new version??

I've already changed the tag testing to the codename Stretch just in case, to prevent that situation. but im not sure, cos i dont understant very well that transiction scenario.

You should change your sources.list when the announcement has been made saying testing is now stable, in this case something like Strech is now stable. update and dist- upgrade will do the trick. I also like doing autoremove when dist-upgrade is done.

Job wrote:You should change your sources.list when the announcement has been made saying testing is now stable, in this case something like Strech is now stable. update and dist- upgrade will do the trick. I also like doing autoremove when dist-upgrade is done.

So then, if you forget it, you would go into new testing and you would mess the installation if you really wanted to pass to stable??, cos you 'd have to rollback to stable from testing. I think, threre should be available a command order to commit that transition..

There is not much difference between a new testing and a new stable but you should pay attention to keep up.

Job wrote:There is not much difference between a new testing and a new stable...

If you don't think of RC bugs as "much difference."

Job wrote:There is not much difference between a new testing and a new stable but you should pay attention to keep up.

How can you say this, if they are two differents versions. This is like is you tell me than Debian Jessie and Debian Stretch are almost the same at the beginning of their line point released. I think you're wrong.. they are differents versions, there must be gap of time before the old testing becomes the new testing, and then a big upgrade with the all new file system, so you need to make the switch to stable if you dont want to miss it, and jump to testing. I think it must be something like that..

Isn't the most stable running old-stable. Tested/fixed through development ... and then live tested (release) with any additional bugs fixed across that test period. Around a 2 year cycle (Jessie/Debian 8 will move into old-stable in a few months time as Stretch is released as the current Stable ... and around 2 years later adopt Stretch as it moves into old-stable as Buster is released as the current stable). Provided you're content to run older (and hence more extensively tested) versions of programs and the kernel works with your hardware/kit. At least that's my plan/policy (presently running Jessie early, does what I want/need and works with my kit, more than happy to continue using it for the next couple of years).

Semantics. For me 'testing' is widely performed over millions of test hours by millions of testers, with around two years between releases/upgrades

so you need to make the switch to stable if you dont want to miss it, and jump to testing. I think it must be something like that..

Nothing like that at all, there is all ways a testing version, When the
new release is ready to be released, it is released as the Debian stable version,
which will be Stretch,... Debian testing, continues to be Debian testing and
it IMMEDIATELY starts moving forward toward the next future release.
When Debian Stretch is released, Debian testing will still be there.

If you do not want to use Debian Stretch at all, and want to keep using testing,
then do not change your sources.list files to Debian Stretch, or Debian Stable,
just keep using Debian Testing.





Look closely, at what "Woody" is saying,....

When a new version is released as stable,it
immediately opens space in the testing, which starts a
new cycle of distribution stabilization for a future release.
ALL processes follows a continuous and natural stream.

There is plenty documentation available on this, but who reads any of it ?
https://wiki.debian.org/DebianReleases
================================

From:https://raphaelhertzog.com/2010/10/18/u ... e-process/
[1] The Constantly Usable Testing project aims to make testing a first-class product like stable—but with a very different update policy.

===================================
https://debian-handbook.info/browse/sta ... cycle.html
===================================

....it
immediately opens space in the testing, which starts a
new cycle of distribution stabilization for a future release

As for what i believed to know, a new and fresh "unstable-testing" release it's nothing to be with an old, mature and "stable-testing" release, thats the reason i was making the point. I was thinking of waiting around six months or so before to do the jump to the next testing version ; changing the tag from testing to stretch or stable and then in six months putting it back to testing and upgrade.

So they're not the same testing one, there must be a gap between libraries base versions, which must be what takes you to the next version of debian once the new cycle has started.

So if you keep your url-tag to testing you will lost your testing-stability system once the cross to the new testing cycle begin (my premise of waiting for six months before to passing from stable to testing).

So, then, why do you not put the stretch address there now? I have hand stretch (and not testing) in my testing set up's sources.list for a year now...

pylkko wrote:So, then, why do you not put the stretch address there now? I have hand stretch (and not testing) in my testing set up's sources.list for a year now...

I recentlly did it, I just wanted to know if i was right about my thoughts, and it seems so.., I probably stay in stretch stable with my laptop until my next computer, mine its a 2008's laptop, that i give it one or two years more.

This is silly I don't have a handle on the inner working of Debian circle but a testing made stable a day ago can't be much different from a testing established a day ago.

I think what bester69 is trying to say is that if your sources.list is pointing to "testing", when "testing" becomes "stable", your sources.list will point to the new "testing" branch instead of stopping when "testing" becomes "stable".

Every new testing branch is given a codename: Wheezy, Jessie, Stretch, etc. If you want to stay with Stretch, for example, when it becomes Stable, then use the codename in your sources.list instead of "testing". When testing starts, you can either use "testing" or "stretch". They point to the same packages, but when Stretch becomes Stable, you'll stay with Stable.

Follow?

phenest wrote:I think what bester69 is trying to say is that if your sources.list is pointing to "testing", when "testing" becomes "stable", your sources.list will point to the new "testing" branch instead of stopping when "testing" becomes "stable".

Every new testing branch is given a codename: Wheezy, Jessie, Stretch, etc. If you want to stay with Stretch, for example, when it becomes Stable, then use the codename in your sources.list instead of "testing". When testing starts, you can either use "testing" or "stretch". They point to the same packages, but when Stretch becomes Stable, you'll stay with Stable.

Follow?

Im very bad trying to explain myself in foreign language , phenest explained better than myself.

if you keep the tag to testing, then the system will jump from Stretch to Buster in one moment, i dont understand how this transiction is done, if it happens in one day, one week, or a month, but if you miss that time, you will find yourself with and unstable version of testing (Buster) instead the very stable of testing version (Stretch).

That leads to why I keep my Debian testing on a separate drive, or VM
The current Debian stable , or any future Stable version, IE; stretch or Debian 9
would go on it's own drive, or VM
The Old stable, Wheezy, Debian 7 is what I keep on the "work station" so to speak.

So if you want the best of both , you could go ahead and upgrade your testing, and when Debian 9 is actually released, that would be your final upgrade.
Install and start a new testing, on a VM or another drive, ...
As far as I know, there is no "official" transition period or time,...

by bester69 » Im very bad trying to explain myself in foreign language

You do better on that then me on that,

Immediately after the release is announced, and actually released, there probably is no difference between the packages, but anyone involved in development could possibly submit new changes, or a new package to testing
at any time, after "testing" is unfrozen,... So if someone likes to follow testing,
and they have changed the sources to Stretch, or stable, they would miss the most recent changes,...of course if and when they switch back to testing, a simple update/upgrade would catch them up as well,
I prefer to keep the "SID", and "Testing" on different drives, I use 2 methods,
Virtual Box VM's and also portable USB drives,with the boot able version on it.
In the past there has usually been a announcement posted on the mailing list,
See https://www.debian.org/News/
Or
https://www.debian.org/News/index.es.html
and somebody posts it here, usually about a week before the new release is released, this gives users a week to change their sources.list if need be.

Job wrote:This is silly I don't have a handle on the inner working of Debian circle but a testing made stable a day ago can't be much different from a testing established a day ago.

I see what you are saying and in theory this is true. That is, when testing is made stable, what happens is that a "snapshot" is taken from a "rolling" package collection and that stays as it is while from where it is taken from continues on rolling. In this sense one would expect testing and stable to be more or less equal in some short period after the transition. However, in practice, during the freeze very little if any new packages from upstream sources are put into the Debian package "universe" (in other words into unstable...some are passed around in experimental but others not at all) and package managers are focusing on other things. Therefore, right after stable is finally stable, most package managers have a lot to catch up to and there is a more-rapid-than-normal influx of new stuff after the transition.

bester69 wrote:i dont understand how this transiction is done, if it happens in one day, one week, or a month

Once Stretch is Stable, a new "testing" is created immediately. However, it can take a few weeks before any changes start to happen.

phenest wrote:

bester69 wrote:i dont understand how this transiction is done, if it happens in one day, one week, or a month

Once Stretch is Stable, a new "testing" is created immediately. However, it can take a few weeks before any changes start to happen.

I believe the phrase that I've read in the wiki, or Deb pages someplace is that the "new" Testing is simply a copy of the new Stable...... in other words for a moment in time they are equivalent. I believe Bester's question is how long, and I would theorize the answer is that "it depends", and "it doesn't matter".

The simple solution here is to change to the code name ahead of time.......I'll have to look, but I think I'm already using "jessie" not "stable", so when Jessie passes to oldstable nothing will change for me.

There doesn't need to be any "what if" here, change it now and be done with it.

Job wrote:This is silly I don't have a handle on the inner working of Debian circle but a testing made stable a day ago can't be much different from a testing established a day ago.

Not "silly" at all.

Stable is released > testing gets opened up to all the juicy new packages that sat in unstable during the freeze prior to release, and packages flood in. Anyone who wanted to migrate to stable after bug hunting in the frozen testing updates after even the first package comes into testing now has a not purely stable system.

This could be within minutes or hours of the stable release, and I would wager almost a certainty within 24-36 hours of release. It's not worth the risk if you wanted to run stable. That is the whole reason for codenames - to avoid situations like this. You ONLY have "testing" in your sources.list if you ONLY want to run testing, otherwise you use the current testing branch code name so as to make a smooth transition to a sane and stable system upon the next stable release.