[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Duplicity-talk] wrt versioning was:Re: Notice for S3/GCS Users

From: edgar . soldin
Subject: [Duplicity-talk] wrt versioning was:Re: Notice for S3/GCS Users
Date: Tue, 31 May 2022 13:06:18 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1

On 27.05.2022 17:30, Kenneth Loafman via Duplicity-talk wrote:
As to substantial upgrade, yes, but with duplicity it's almost as though
the leading zero was not there.  Been thinking about moving to 8.23.0

that's like introducing a full new scheme. and confusing too. nuhh don't like 

instead of 0.8.23 so I could have a point release.

well, actually you can already. two possibilities -

say current scheme is major.minor.patch(not really currently)

1. decide next major evolution goes into the major version e.g. remove python2 
support v1.0.0
 that'll free up minor version to signal functional changes and patch for fixes 
only e.g.
 1.0 remove python2 support
 1.0.1 just some fixes
 1.1 change of functionality
2. just add an actual patch value e.g.
 0.8.23 release just some fixes
 0.8.24 functional update

food for thought - as versioning does not need to go from 0.9 tom 1.0 we can 
stick in 0.xx for as long we want by just incrementing the second value until 
there is like a total rework/incompatibility e.g. switching the backup format 
or such.

also, with the plethora of backends we will would probably need to raise major 
version all the time to signal some backward compatibility break. as that seems 
unfeasible. i'd say users should use known working backup software or will have 
to retest on upgrades themselves. it's just wantonly negligent to blindly 
upgrade backup software _in_active_use_ to an unknown state ;)

just my 2 cents.. ede

reply via email to

[Prev in Thread] Current Thread [Next in Thread]