duplicity-team team mailing list archive

[Peter Schuller <peter.schuller@xxxxxxxxxxxx>]

Hello,

now that duplicity is on launchpad and the universe is suddenly
looking bright and shiny (= easy to branch, tag, etc), do you think it
would be worth the effort to maintain stable and unstable releases
separately, similarly to rdiff-backup?

We've had some cases where there have been releases to avoid, such as
the 6.00. But it's still good to have these releases since early
adopter test them and provide feedback.

What I'd hate to see happen is that debian/rhel/etc makes a new
release and ends up grabbing such a "not recommended" release because
it was the latest version at the right (wrong) moment. The result
would likely be (1) support hell for 4+ years, (2) unnecessary bad
reputation because of many people having issues over a significant
period of time.

Thoughts? My suggestion is not necessarily to do it like rdiff-backup
where they maintain two branches for an extended period. But something
we could do is to "promote" unstable versions, such that you'd have
for example:

Unstable releases:

  3.1.5   2.1.6   3.1.7   3.1.8

And for example, 3.1.5 and 3.1.7 may have turned out to be stable
recommended releases, so at various points in time they were promoted
to stable, such that there are stable versions:

  3.1.5 3.1.7

In other words, maintain a direct correspondence between
stable/unstable, but treating the unstable releases kind of like
pre-releases.

Of course I realize just now that this might be all equivalent to
simply having pre-releases instead of maintaining stable/unstable
version systems... I guess the only reason I can think of to not do
pre-releases is that a pre-release probably gives an impression of
"bleeding edge" that is more extreme than one might intend in this
case. I.e., the "unstable" are really real releases, but only
recommended for cases where people can keep up-to-date, and 'stable'
is stable in the sense of being suitable for slow upgrades and package
management in long-cycle distributions.

Anyways, I think there's a good motivation to do *something*, though
keeping it simple is always nice.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@xxxxxxxxxxxx>'
Key retrieval: Send an E-Mail to getpgpkey@xxxxxxxxx
E-Mail: peter.schuller@xxxxxxxxxxxx Web: http://www.scode.org

Attachment: pgpZz5bztAS6v.pgp
Description: PGP signature