>>I'll bow to Bhaskar on making the case for how many versions isThat much is true for *any* software that's reasonably managed so
>>reasonable to have in the future as we maintain a sliding window
>>of them.
>[KSB] Since a GT.M release is frozen for all time once it's released,
that's not really that useful.
I suppose people setting up a new Mumps environment
> one answer is as many releases as we have disk for.
> Another answer is that although we periodically get
> e-mails from people with five and ten year old releases,
> we normally consider releases to have a two year window of peak use,
> and maintaining three years' worth is a good number. That will probably
> translate to about ten releases.
can be expected to use the latest stable released
version.
People should pin their installed version until they
are ready to upgrade.
Maybe we need to clarify one point: are people
typically "expected to upgrade" / "upgrading" from
one "stable" version to the next at all ?
Are there *any* in-place upgrades (think PG 9.3.1 to 9.3.2)
or will upgrading *always* require a "dump/restore" cycle ?
What will typically (be made to) happen to any given deployment
when a new "Major" / "minor" version is released ?
Karsten
Archive: [🔎] trinity-2ded2296-72d0-4245-9871-e5a060a63bbb-1391742963566@3capp-gmx-bs24" target="_blank">http://lists.debian.org/[🔎] trinity-2ded2296-72d0-4245-9871-e5a060a63bbb-1391742963566@3capp-gmx-bs24
--
To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org