What's in a Version Number?
Yuval Levy
During a private discussion after LGM Pablo had this idea which I think
now is the time to implement. Details at
<http://panospace.wordpress.com/2009/07/19/whats-in-a-version-number/>
From now on let's use the major version number (padded to four digits)
for the year, the minor version number for the month (padded to two
digits) and the third version number to distinguish snapshots (.0) final
(.1) and bug fixes (>.2)?
so Hugin 0.8.0 becomes Hugin 2009.07.1
If there is no opposition to this suggestion we shall move quickly to
make the changes in SVN and release 2009.07.1 before new features make
the trunk unstable again.
future snapshots become Hugin YYYY.MM.0.SVN
Yuv
Guido Kohlmeyer
What do you propose to deal with development steps for patches?
The naming yyyy.mm.n, with n > 1 is o.k. for a release of a patch, but
how to distinguish development snapshots of patches? I expect a patch
will be done on a branch rather than on the trunk, and the fixes will be
integrated in the trunk as well. I guess this is not often needed, but
if there is a process, we can use it.
So, should we proceed with yyyy.mm.0.SVN? Unfortunately you cannot see,
whether this shnapshot is taken before of after yyyy.mm.1 if yyyy.mm are
the same. Futhermore is is not visible whether it is a snapshot of
branch or trunk. A developer can trace back the SVN number to trunk or
branch using SVN. Maybe this is sufficent and end-users should only take
the non-SVN versions into account, which were numbered increasingly. I
expect patches are based on the year and month of their corresponding
final version although they may be relased at least a month later.
I don't want to start a big discussion about it. Maybe you already
discussed such szenario already with Pablo.
Guido
Lukáš Jirkovský
I'm not sure if it's really good idea. The problem is that numbering
SVN snapshots could become messy. First I'd change the version number
in about immediately after release X to X+1 so everyone would know
that it's version after the release. This means that current svn head
would have version number 0.9.0.4012. Everyone would see that it's
newer than 0.8.0 but it's snapshot before 0.9.0, not final 0.9.0.
I'm afraid that the numbering you are proposing will result in lots of
builds named eg. 2009.08.0.4025, 2009.08.0.4026, 2009.12.0.4168 and
final would be eg 2010.04.1. You can see that find the version which
is stable is not very easy.
But I agree that Hugin deserves version number which doesn't begin with zero.
Just my 2 cents.
Lukáš
Bart van Andel
already putting files in a folder named Hugin-x.y.z.SVN (latest one on
disk: Hugin-0.8.0.4012), but I like the date-like versioning probably
even better.
--
Bart
Yuval Levy
> Hi Yuv,
>
> What do you propose to deal with development steps for patches?
> The naming yyyy.mm.n, with n > 1 is o.k. for a release of a patch, but
> how to distinguish development snapshots of patches?
if you patch 2008.10.1 today, it becomes 2008.10.2 (and not 2009.07.n)
> A developer can trace back the SVN number to trunk or
> branch using SVN. Maybe this is sufficent and end-users should only take
> the non-SVN versions into account
for snapshots the only thing that really counts is SVN and the
information about backporting of patches is not really relevant.
There are a number of possibilities. Say we make a snapshot in August
2009 of SVN 4444:
1) 0000.00.0.4444
+: SVN number is all testers and developers need
-: users are completely at loss in placing the snapshot in the timeline
2) 2009.00.0.4444
=: would give the user slightly more information but not enough
3) 2009.07.0.4444
+: identifies relationship with last release (2009.07.1)
-: does not say if it is newer or older
4) 2009.08.0.4444
+: better placement on timeline
-: short term confusion (e.g. if we released 2009.08.1.4343)
IMO what counts for snapshot is SVN only, so the goal is to find the one
that leads to the least confusion.
My preference would be (1) because it is easier to maintain (for the
others we'd need to remember to bump up the version numbers in trunk
every month or every year); because we are telling our testers to
indicate the SVN version in the bug reports; because the power users who
do use snapshots are looking at the SVN number only anyway while the
yyyy.mm.n scheme is for the "normal" users who should stay away from
snapshots anyway.
> Maybe you already
> discussed such szenario already with Pablo.
honestly not.
Yuv
Yuval Levy
Lukáš Jirkovský wrote:
> First I'd change the version number
> in about immediately after release X to X+1 so everyone would know
> that it's version after the release.
oh, I'd love that - then we'd have a fixed release schedule, monthly :)
> I'm afraid that the numbering you are proposing will result in lots of
> builds named eg. 2009.08.0.4025, 2009.08.0.4026, 2009.12.0.4168 and
> final would be eg 2010.04.1. You can see that find the version which
> is stable is not very easy.
you tipped my preference for the snapshots to be simply 0000.00.0.SVN
0000.00.0.4025, 0000.00.0.4026, 0000.00.0.4168 and final 2010.04.1
> But I agree that Hugin deserves version number which doesn't begin with zero.
it also deserves a more regular release cycle. I've suggested already
one that we have a meeting once a month to decide if trunk is worth
releasing and try to release more often.
my wish would be for the next releases to be:
2009.08.1: vigra update (your big patch) + incremental changes (i.e.
some of the things that Thomas or Gerry have withheld due to our freeze)
2009.09.1: nona-gpu
so that we are ready to integrate the GSoC projects in the automn,
ideally also one month at a time, e.g.
2009.10.1: enfuse/deghosting (your GSoC 2009 project)
2009.11.1: new panorama layout (James' GSoC 2009 project)
2009.12.1: lens calibration (Tim's GSoC 2009 project)
2010.01.1: mosaic mode (Dev's GSoC 2009 project)
probably some of the above releases will get stretched out to two or
three months (and push the following ones, or maybe move beyond them);
and there will be some "natural" cruising speed in terms of releases.
At the moment our releases are too big and too slow. I want them to be
more incremental, i.e. smaller chunks of new code. They will become
faster by the nature of the changes.
Yuv
Bruno Postle
>Lukáš Jirkovský wrote:
>> First I'd change the version number
>> in about immediately after release X to X+1 so everyone would know
>> that it's version after the release.
We do need this, e.g. the trunk needed to be renamed 0.8.0
immediately after the 0.7.0 release so it was clear that any
snapshots were 0.8.0 pre-releases.
>oh, I'd love that - then we'd have a fixed release schedule, monthly :)
..or it indicates a problem with a date based scheme, for packaging
snapshots I'd really like the V_MAJOR,V_MINOR,V_PATCH settings in
the trunk to be the same as the next release.
A date based scheme presumes we know when this release will be
(though we should be able to get the year right at least ;-)
>> I'm afraid that the numbering you are proposing will result in lots of
>> builds named eg. 2009.08.0.4025, 2009.08.0.4026, 2009.12.0.4168 and
>> final would be eg 2010.04.1. You can see that find the version which
>> is stable is not very easy.
Also putting the svn revision in the tarball name is a problem.
Package databases will read hugin-2009.08.0.4025 as more recent than
hugin-2009.08.0
>you tipped my preference for the snapshots to be simply 0000.00.0.SVN
>
>0000.00.0.4025, 0000.00.0.4026, 0000.00.0.4168 and final 2010.04.1
This doesn't work. When packaging, newer releases need to have a
higher number than older releases - rpm and apt package databases
actually use these numbers.
The current trunk now generates a tarball called
hugin-0000.00.0.tar.gz this needs to be fixed. I not really
bothered that we change the numbering scheme, for me any of these is
ok for the next stable release (i.e. a release with new features):
0.9.0
1.0.0
2009.2.0
I would like 2009.2.0 to mean 'second stable release in 2009', a
bugfix update to this would be 2009.2.1 etc... the next feature
release would be 2009.3.0 etc...
>> But I agree that Hugin deserves version number which doesn't begin with zero.
Yes, we should have moved to 1.0.0 when we did 0.7.0 as this was the
first release that was of a quality for general users.
>it also deserves a more regular release cycle. I've suggested already
>one that we have a meeting once a month to decide if trunk is worth
>releasing and try to release more often.
>
>my wish would be for the next releases to be:
>2009.08.1: vigra update (your big patch) + incremental changes (i.e.
>some of the things that Thomas or Gerry have withheld due to our freeze)
>2009.09.1: nona-gpu
nona-gpu needs to go in immediately, it has been in limbo for most
of a year. We can't expect top developers like Andrew to contribute
in future if major work like this doesn't get released.
>so that we are ready to integrate the GSoC projects in the automn,
>ideally also one month at a time, e.g.
>
>2009.10.1: enfuse/deghosting (your GSoC 2009 project)
>2009.11.1: new panorama layout (James' GSoC 2009 project)
>2009.12.1: lens calibration (Tim's GSoC 2009 project)
>2010.01.1: mosaic mode (Dev's GSoC 2009 project)
Yes, but the mistake we made with 0.8.0 was that we didn't realise
the Batch processor wasn't ready to merge and needed a lot of work.
Looking back I don't see how we could have known this.
Conversely, if we had decided to wait for the Batch Processor to be
ready then it would probably be no further along, and likely never
have been released.
--
Bruno
Yuval Levy
> I'd really like the V_MAJOR,V_MINOR,V_PATCH settings in
> the trunk to be the same as the next release.
is it possible to run a cron script at the beginning of every month with
the following logic:
V_MINOR=V_MINOR+1
if month=1 V_MAJOR=V_MAJOR+1
> A date based scheme presumes we know when this release will be
> (though we should be able to get the year right at least ;-)
I would not put this in stone :-)
> Putting the svn revision in the tarball name is a problem.
I never suggested putting the SVN revision in the tarball name. If I
generated confusion on this, I apologize.
we currently have V_MAJOR,V_MINOR,V_PATCH, and we have HUGIN_WC_REVISION
which is SVN.
AFAIK HUGIN_WC_REVISION is not used in tarball name? it is used in the
About dialog and in the Windows installer name.
> Package databases will read hugin-2009.08.0.4025 as more recent than
> hugin-2009.08.0
indeed this is why I suggest to keep V_PATCH = 0 in trunk and set
V_PATCH = 1 for the final release and then V_PATCH=V_PATCH+1 for every
subsequent bugfix (which should be very very *very* infrequent).
>> you tipped my preference for the snapshots to be simply 0000.00.0.SVN
>>
>> 0000.00.0.4025, 0000.00.0.4026, 0000.00.0.4168 and final 2010.04.1
>
> This doesn't work. When packaging, newer releases need to have a
> higher number than older releases - rpm and apt package databases
> actually use these numbers.
would YYYY.MM.0 work? with the script mentioned above updating YYYY.MM
as the calendar moves, and with the release engineer setting V_PATCH to
1 on final release?
> The current trunk now generates a tarball called
> hugin-0000.00.0.tar.gz this needs to be fixed.
oh, so it does not use SVN :-)
> I would like 2009.2.0 to mean 'second stable release in 2009', a
> bugfix update to this would be 2009.2.1 etc... the next feature
> release would be 2009.3.0 etc...
using the first/second/third release instead of the month could be a
good compromise.
Is there any reason why you want to stick to V_PATCH=0 for the release
rather than V_PATCH=1?
> nona-gpu needs to go in immediately, it has been in limbo for most
> of a year. We can't expect top developers like Andrew to contribute
> in future if major work like this doesn't get released.
Agree. If nobody opposes this, I suggest that we get on with nona-gpu as
2009.08.1 release (or 2009.2.0 if you prefer).
First we should mark to priority 9 the bugs that we want / need to fix
for the release.
<https://sourceforge.net/tracker/?func=detail&aid=2535997&group_id=77506&atid=550441>
seems to be the single one that is critical.
Then we need to merge
<http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/branches/nona-gpu/>
into trunk. Any volunteer? Andrew?
Then we need to fix and test the prio 9 bugs, and look at the
translation differences.
Release beta, RC1, maybe RC2, final.
If it is OK for you (and you're available if I have questions) I'll be
happy to play the role of 'release-engineer' that you had for the 0.7.0
and 0.8.0 releases. I'll try to document everything so that other
community members can step in for later releases, and so that we can, as
a team, replace each other when in need.
> the mistake we made with 0.8.0 was that we didn't realise
> the Batch processor wasn't ready to merge
without dwelving too much on the past, and with no intention of finger
pointing, every one of the three projects needed some work. Tim worked
tirelessly with Harry and me to make Celeste work in OSX and Windows.
James got help from Guido, Thomas, Rick and others with details of the
fast preview that required polishing before release. You, Thomas and
others worked on cleaning up PTbatcher. The consequences of doing all of
this on the same trunk was to streeeeetch the release cycle beyond
necessary, and the result of the stretch is reduced energy levels.
> Conversely, if we had decided to wait for the Batch Processor to be
> ready then it would probably be no further along, and likely never
> have been released.
yes, there are trade-offs. and yes, it takes the courage to take
something that is 90% complete, drop it in trunk and focus on it to fix
it. all things being equal it is better/easier to do so one project at a
time. in hindsight we can always be smarter. in the end everybody
involved produced a great effort with an excellent result we can all be
proud of. thanks to everybody who contributed and who continues to
contribute to this experience in continuous improvement :)
Yuv
T. Modes
> nona-gpu needs to go in immediately, it has been in limbo for most
> of a year. We can't expect top developers like Andrew to contribute
> in future if major work like this doesn't get released.
>
I asked for help about 2 months ago (http://groups.google.com/group/
hugin-ptx/browse_thread/thread/663db5bc2aab2846/c29a5251335f40e2), but
there was no big response.
In the meantime my local version with some changes compiles. But the
result is not satisfacting, because only the first line of the output
images is calculated. Currently I have no time to look deeper into it,
maybe someone other can help.
I think, the branch should work in principle (on the main platforms)
before we merge it with trunk.
Thomas
Bruno Postle
>Bruno Postle wrote:
>> I'd really like the V_MAJOR,V_MINOR,V_PATCH settings in
>> the trunk to be the same as the next release.
>
>is it possible to run a cron script at the beginning of every month with
>the following logic:
>
>V_MINOR=V_MINOR+1
>if month=1 V_MAJOR=V_MAJOR+1
What I mean is that during the 'release candidate' phase (and
probably during the 'beta' phase too), you need the x.x.x version to
be exactly the same as the final release.
So as soon as you have a branch (or trunk) that you know is going to
become a release, it makes sense to have that number in place.
..unless you dont know what the final release will be called because
it will depend on the date, but that makes writing documentation
difficult.
Alternatively we could decide now that the next release is targetted
for September and will be hugin-2009.9.0 - And it will still be
2009.9.0 even if it slips by a couple of months ;-)
>> I would like 2009.2.0 to mean 'second stable release in 2009', a
>> bugfix update to this would be 2009.2.1 etc... the next feature
>> release would be 2009.3.0 etc...
>
>using the first/second/third release instead of the month could be a
>good compromise.
>
>Is there any reason why you want to stick to V_PATCH=0 for the release
>rather than V_PATCH=1?
It is ok so long as the current trunk has a higher number than the
most recent stable release, but also has a higher number than a
possible patched stable release.
e.g. the current trunk needs to have a higher number than 0.8.0, but
also higher than 0.8.1
>If it is OK for you (and you're available if I have questions) I'll be
>happy to play the role of 'release-engineer' that you had for the 0.7.0
>and 0.8.0 releases. I'll try to document everything so that other
>community members can step in for later releases, and so that we can, as
>a team, replace each other when in need.
I'd still work on the tarball and install CMake rules, but you are
welcome to the announcement/upload/etc.. stuff.
--
Bruno
Lukáš Jirkovský
add svn version to it? So the stable release would be eg 2009.07.0 (or
.1 or whatever you like) and the development version would be eg.
2009.07.4075 This would avoid confusion when the release is from some
reason postponed (when the svn version would be
expected_date_of_release.0.svn_revision) and it would also avoid
problem where the svn versions have lower number than stable (when svn
version would be 0000.0.0.svn_rev). I'm quite sure that we will never
release 4075 fixes to the current stable so it wouldn't interfere with
stable.
Lukáš
Rich
while that might confuse a user here or there, i believe that't better
than 0000.00.0 syntax.
what about 2009.07.dev-<rev> ?
that would make it easier for casual users to figure out what's what
> Lukáš
--
Rich
Bruno Postle
>
>what about 2009.07.dev-<rev> ?
>that would make it easier for casual users to figure out what's what
Sorry this stuff is actually used by Linux packaging systems, please
can we just have:
Three numeric numbers in the version.
The numbers only change after a stable release, a constantly
changing version is a real pain.
Branches/trees have a higher number than the stable release they are
derived from.
Windows and OS X installers can be called whatever you like.
--
Bruno
Rich
> On Tue 21-Jul-2009 at 15:30 +0300, Rich wrote:
>> what about 2009.07.dev-<rev> ?
>> that would make it easier for casual users to figure out what's what
>
> Sorry this stuff is actually used by Linux packaging systems, please
> can we just have:
>
> Three numeric numbers in the version.
>
> The numbers only change after a stable release, a constantly
> changing version is a real pain.
then just stick with 0.8 branch, move to 1.0 version at the nxt stable
release and so on ;)
personally, i don't see problems with the current scheme, except maybe
the minor gain of figuring out package age from the name immediately.
> Branches/trees have a higher number than the stable release they are
> derived from.
>
> Windows and OS X installers can be called whatever you like.
--
Rich
Yuval Levy
> Three numeric numbers in the version.
2009.07.1 ?
> The numbers only change after a stable release, a constantly
> changing version is a real pain.
ok, so forget my idea of havin MAJOR_V/MINOR_V tracking time.
MAJOR_V/MINOR_V should be bumped only when branching toward release.
> Branches/trees have a higher number than the stable release they are
> derived from.
this I don't fully understand. I understand that a bugfix on 0.7.0 needs
a higher number than 0.7.0 itself; and I understand that a newer release
needs to have a higher number than 0.7.0 itself; what I fail to see is
the relevance of version number for trunk.
best practice is to release from branches, not from trunk. So setting
the version number when branching out for release should be good enough?
If trunk is 0000.00 then all branches have a higher number than trunk.
Trunk is anyway relevant only for development and version number is
irrelevant for trunk.
> Windows and OS X installers can be called whatever you like.
this is not about Windows and OS X.
When I see a bug report against a release, a version number is enough.
This includes Windows and OS X. When I see a bug report against a nighty
/ snapshots, I don't really care the version number. What I do care is
the SVN number and possibly the branch from which it cames. As long as
trunk does not identify itself as a release, that's fine for me when I
wear my hat of bug triager.
SUMMARIZING:
- trunk has always version 0000.00.0 (it's irrelevant anyway)
- snapshot builds include the SVN in the human readable name (e.g. the
about windows) for usage in bug reports
- when branching out for release, a version number is assigned. Can be
YYYY.MM.n or YYYY.increment.n. n can be 0 or 1, I am OK with both.
- when patching a branch, n is incremented.
this way:
- The version numbers are relevant for releases only and only change
after a stable release
- The order in the numbers is kept (newer version, bigger number)
with the advantages that:
- whoever builds trunk / uses nightly does not report the bug against a
release but against a very specific trunk status
- the release number is determined by the time at which we decide to
release (no need to discuss if the addition of a feature warrants a
major or minor version number increase)
- give the users a clear sense of where in time was the release
- adapts to the naming scheme of the most popular Linux distribution
Yuv
Bruno Postle
>Bruno Postle wrote:
>> Three numeric numbers in the version.
>
>2009.07.1 ?
Fine.
>> The numbers only change after a stable release, a constantly
>> changing version is a real pain.
>
>ok, so forget my idea of havin MAJOR_V/MINOR_V tracking time.
>MAJOR_V/MINOR_V should be bumped only when branching toward release.
>
>> Branches/trees have a higher number than the stable release they are
>> derived from.
>
>this I don't fully understand. I understand that a bugfix on 0.7.0 needs
>a higher number than 0.7.0 itself; and I understand that a newer release
>needs to have a higher number than 0.7.0 itself; what I fail to see is
>the relevance of version number for trunk.
I build regular snapshots of hugin for myself, but I package them as
rpms and put them in a publically available yum repository.
It only takes 15 minutes or so to build from scratch with mock and
is a good test of the tarball creation, installation scripts,
desktop integration and dependencies - i.e. a lot of stuff. There
are also a number of people who subscribe to this repository and
give excellent feedback when things break. Because I know _exactly_
what is in these packages, it is easy to track down problems.
(I'd really like somebody else to do the same for ubuntu, but
properly and certainly not with 'checkinstall')
The tarball name and hence the rpm package name are derived from the
x.x.x version. For this repository to work I need this number to
make sense, i.e. people can subscribe and thereby automatically
replace the fedora hugin 0.7.0 or 0.8.0 stable release with the
moving snapshot, if they unsubscribe then they will live with a
snapshot until the next official fedora feature release at which
point they are seamlessly back to where they started. The x.x.x
number must never go backwards, this breaks everything.
--
Bruno
Yuval Levy
> On Tue 21-Jul-2009 at 14:50 -0400, Yuval Levy wrote:
>> I fail to see is
>> the relevance of version number for trunk.
>
> I build regular snapshots of hugin for myself, but I package them as
> rpms and put them in a publically available yum repository.
thanks for sharing this with us. I did not know. I find it good if this
would be documented in
<http://wiki.panotools.org/Hugin_Compiling_Fedora> - down to a level
that a total Fedora newbie can set up the same infrastructure that you
currently provide.
> (I'd really like somebody else to do the same for ubuntu, but
> properly and certainly not with 'checkinstall')
would be nice indeed. Who has the know-how? Please add it to
<http://wiki.panotools.org/Hugin_Compiling_Ubuntu> - how to make the
tarball, how to make the deb file (both source and binary), how to run a
repository.
For Windows this is what I have been doing in the run up to 0.7.0
release and what Ad has been doing for 0.8.0 and keeps doing.
And for OSX it is what Harry does.
> The tarball name and hence the rpm package name are derived from the
> x.x.x version. For this repository to work I need this number to
> make sense, i.e. people can subscribe and thereby automatically
> replace the fedora hugin 0.7.0 or 0.8.0 stable release with the
> moving snapshot,
do I understand it right that if trunk has 0.0.0, then subscribing will
result in no action (since the offical fedora feature release is already
0.7.0)?
are you releasing tarballs of betas and RCs, or also of arbitrary SVN
versions like Ad does?
what would happen if these people would unsubscribe / remove the
official feature release before subscribing to your repository with 0.0.0 ?
> if they unsubscribe then they will live with a
> snapshot until the next official fedora feature release at which
> point they are seamlessly back to where they started.
and if they unsubscribe at 0.0.0, would the next official fedora feature
release get them to the same place?
Yuv (trying to make sense of this part of the snapshot release process
that I was not aware of)
Rich
...
>> The tarball name and hence the rpm package name are derived from the
>> x.x.x version. For this repository to work I need this number to
>> make sense, i.e. people can subscribe and thereby automatically
>> replace the fedora hugin 0.7.0 or 0.8.0 stable release with the
>> moving snapshot,
>
> do I understand it right that if trunk has 0.0.0, then subscribing will
> result in no action (since the offical fedora feature release is already
> 0.7.0)?
with absolute majority of the package managers i would expect that, yes.
this is a reason why after a branch is created, trunk should get version
bumped.
when a release is tagged from branch, branch itself has the version
bumped, so that release version always denotes release and there is no
ambiguity about whether it's release or some point later in time svn
version.
for hugin it could be like :
0.8 branch goes on, but immediately after 0.8.0 is released, branch
version is bumped to 0.8.1. when 0.8.1 is tagged, branch version is
bumped to 0.8.2.
now, trunk, immediately after 0.8 was branched, gets some other version,
which, depending on approaches i have seen, could be something like
0.9.0 or 0.8.<some large number>. personally, i prefer the former.
and again, there are two options - 0.9 can be declared development
version, or it can be used for the final version number. if it's
declared dev version, regular "releases" can be made with sequential
numbers - 0.9.0 could be like alpha1, 0.9.1 alpha2, ... 0.9.6 beta1 and
so on.
when it is considered stable enough, 1.0 is branched and trunk gets
version bumped to 1.1.
with such a scheme every next version always has a bigger version number.
now what about svn snapshots from trunk or branch ?
here, svn number can always be added - something like 0.9.1-4444
> are you releasing tarballs of betas and RCs, or also of arbitrary SVN
> versions like Ad does?
as "snapshots" were mentioned, i expect those to be mostly trunk snapshots.
> what would happen if these people would unsubscribe / remove the
> official feature release before subscribing to your repository with 0.0.0 ?
i don't like the 0.0.0 version - it indeed looks like it's broken, is
confusing and will cause problems like the mentioned ones with package
managers
>> if they unsubscribe then they will live with a
>> snapshot until the next official fedora feature release at which
>> point they are seamlessly back to where they started.
>
>
> and if they unsubscribe at 0.0.0, would the next official fedora feature
> release get them to the same place?
>
> Yuv (trying to make sense of this part of the snapshot release process
> that I was not aware of)
--
Rich
Thomas Steiner
2009/7/21 Bruno Postle <br...@postle.net>:
> On Tue 21-Jul-2009 at 14:50 -0400, Yuval Levy wrote:
>>Bruno Postle wrote:
>>> Three numeric numbers in the version.
>>
>>2009.07.1 ?
>
> Fine.
why don't you use 09.07.1 instead? 2009 is so long...
Thomas
RizThon
Bruno Postle
>
>do I understand it right that if trunk has 0.0.0, then subscribing will
>result in no action (since the offical fedora feature release is already
>0.7.0)?
That's right.
>are you releasing tarballs of betas and RCs, or also of arbitrary SVN
>versions like Ad does?
SVN version, which is logged in the .spec file. The rpm also has
the date appended to the file name - Which is the fedora policy for
SVN snapshots (these rpms are always in a state where I could push
them into fedora proper without changes).
There is also always an rpm for each rc/beta tarball release, since
this is one of the checks I do. But since the check happens before
the release, it can never be labelled as such.
>what would happen if these people would unsubscribe / remove the
>official feature release before subscribing to your repository with 0.0.0 ?
They can't unsubscribe to the official fedora repository, so given a
choice between 0.0.0 and 0.7.0 the package manager will always go
for 0.7.0.
>and if they unsubscribe at 0.0.0, would the next official fedora feature
>release get them to the same place?
No the 0.0.0 version could never be installed via a repository, if
it was installed manually then it would get 'upgraded' by the older
official fedora package at next 'software update'.
--
Bruno
Yuval Levy
>> what would happen if these people would unsubscribe / remove the
>> official feature release before subscribing to your repository with 0.0.0 ?
>
> They can't unsubscribe to the official fedora repository
oh, I thought that this is about unsubscribing from the package.
so sub/unsub is repository related.
then let's try the other way around:
what happens if we do 9.9.9 instead of 0.0.0
somebody is subscribed to fedora and subscribes to you. will 9.9.9
install over 0.7.0?
and if they want to get back to the next release they have to first
remove 9.9.9, unsubscribe from you, and then reinstall 0.7.0, as opposed
to simply wait for the official fedora repository to push the next release?
Yuv
Bruno Postle
>Bruno Postle wrote:
>>> what would happen if these people would unsubscribe / remove the
>>> official feature release before subscribing to your repository with 0.0.0 ?
>>
>> They can't unsubscribe to the official fedora repository
>
>oh, I thought that this is about unsubscribing from the package.
You can subscribe to a repository and/or a package name, the package
'hugin' could be provided by multiple repositories. There are also
various things equivalent to 'pinning' in debian that you don't want
to get into.
>somebody is subscribed to fedora and subscribes to you. will 9.9.9
>install over 0.7.0?
Yes.
>and if they want to get back to the next release they have to first
>remove 9.9.9, unsubscribe from you, and then reinstall 0.7.0, as opposed
>to simply wait for the official fedora repository to push the next release?
Yes. There is also the possibility that my repository doesn't get
updated for one reason or another, in this case you want to to
seamlessly upgrade to the offical fedora package once that catches
up.
--
Bruno
Yuval Levy
> You can subscribe to a repository and/or a package name, the package
> 'hugin' could be provided by multiple repositories. There are also
> various things equivalent to 'pinning' in debian that you don't want
> to get into.
why not ('pinning')?
let's not forget that we are dealing with snapshots vs. releases.
releases are for the general public. snapshots are for "those who know
what they are doing". Requiring snapshot users to do 'pinning' does not
seem excessive to me.
>> somebody is subscribed to fedora and subscribes to you. will 9.9.9
>> install over 0.7.0?
>
> Yes.
>
>> and if they want to get back to the next release they have to first
>> remove 9.9.9, unsubscribe from you, and then reinstall 0.7.0, as opposed
>> to simply wait for the official fedora repository to push the next release?
>
> Yes. There is also the possibility that my repository doesn't get
> updated for one reason or another, in this case you want to to
> seamlessly upgrade to the offical fedora package once that catches
> up.
A seamless upgrade is always wishful. For releases it is a must. For
snapshots I don't think so. Asking snapshot users who want to revert to
releases to make a simple manipulation such as remove the snapshot
before reinstalling the release does not seem too much IMO.
When the general public starts to use snapshot releases (or self-rolled
builds) it means that we are not releasing often enough.
releases belong in branches separated from trunk to minimize the freezes
on trunk. Version numbers will be kept consistent within and between
branches by bumping the version number immediately after branching and
before release. the number of commits between branching and release
should be kept to a minimum - all geared at polishing the release. Trunk
keeps on moving forward.
Yuv
Yuval Levy
Thomas Steiner wrote:
> why don't you use 09.07.1 instead? 2009 is so long...
are you so young that you never heard of the Y2K bug ;-) ?
of course we could also count in Unix Epoch time, or in years since
Hugin was born, but the Gregorian calendar is the internationally
accepted civil calendar.
Yuv
Tahoe Dave
real version was 3.1 then what? 98, ME, 2000, xp Vista, 7? Yikes.
Rogier Wolff
>
> Bruno Postle wrote:
> > You can subscribe to a repository and/or a package name, the package
> > 'hugin' could be provided by multiple repositories. There are also
> > various things equivalent to 'pinning' in debian that you don't want
> > to get into.
>
> why not ('pinning')?
>
> let's not forget that we are dealing with snapshots vs. releases.
>
> releases are for the general public. snapshots are for "those who know
> what they are doing". Requiring snapshot users to do 'pinning' does not
> seem excessive to me.
with snapshots numbered completely different, problems arise, that's
why you're having this discussion. How about something similar to the
Linux kernel. Odd numbered versions are development, even numbered are
releases.
2009.06.0 <- Prerelease. (release candidate).
2009.06.1 <- release.
2009.06.2 <- bugfix release
2009.07.4567 <- svn number development after 2009.06...
2009.07.4568
2009.08.0 <- Prerelease...
If within less than two months you want to have two real releases,
you'll have to "run ahead" maybe a bit with the version numbers. No
biggie. Time will catch up eventually.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Rogier Wolff
>
> I won't comment about likes and dislikes - we all have them...
>
> Thomas Steiner wrote:
> > why don't you use 09.07.1 instead? 2009 is so long...
>
> are you so young that you never heard of the Y2K bug ;-) ?
On the other hand, defining (like ubuntu) that number as the year
minus 2000, that will only become awkward in the year 3000: Only then
are you no longer saving a digit.... What happens in the year 3000
is not really of personal concern for me....
Yuval Levy
> How about something similar to the
> Linux kernel. Odd numbered versions are development, even numbered are
> releases.
sounds good to me.
> If within less than two months you want to have two real releases,
> you'll have to "run ahead" maybe a bit with the version numbers.
I think Bruno's idea to use an increment instead of the month is more
appropriate then, even if the day we will want to have two real releases
within less than two months is probably more far away than Y3K :)
Can we agree on:
V_MAJOR: YYYY
V_MINOR: sequential, odd for development. and even for stable.
V_PATCH: for bugfixes on releases
?
* right now we'd be 2009.1 in trunk
* the next release, with nona-gpu, will hopefully be 2009.2; or it will
be 2010.0
* after the next release trunk will be bumped to 2009.3 or 2010.1
respectively
the release branching process becomes:
1. when ready to go in release mode, if there was a year change, sync
V_MAJOR to the current year.
2. branch out the release branch.
3. in the release branch, bump up V_MINOR to the next even number
4. issue the first tarball (beta) from the release branch
5. in trunk, bump up V_MINOR to the next odd number
6. commit into the release branch only changes required to polish / fix it
7. issue a series of release candidates from the release branch
8. declare the release branch final
9. minimum maintenance on branch
there have been different opinions voiced about trunk freeze vs.
branching release and letting trunk live. While respecting all opinions
- motivation is something personal to each and every individual - I
think that imposing a trunk freeze is contrary to the nature of letting
software flow free.
Open source resources are self-directed. People make decisions for
themselves when/what/where they want to contribute. If there is enough
interest for a polished release, it will happen.
For the past two releases we had the approach of cumulating a lot of
trunk development before going into release mode. The pressure has grown
so much that the snapshots have become so much user attention and
eventually we had a release. In doing so we played a trade-off between
those who want the release and those who want to develop further against
the latter, artificially slowing down people like Andrew (nona-gpu) or
Lukáš (vigra-1.6).
Once branched, the release branch may flourish to a polished full and
final release, or it may dry and be superseded by the next cycle. This
will be an indication whether we branched too early / with not enough
interesting features or there was a real need for a release.
The plan I currently suggested is a flurry of releases. nobody says this
is the right thing to do. It is just an experiment.
If we align five release branches (nona-gpu; vigra; new panorama layout;
lens calibration; mosaic mode) and they all flourish to release, I will
be lucky at 100%. If we get only three releases in between (i.e. two of
them don't move past the beta) it will still be better than the past two
years / crops of GSoC projects. And even if we get only one, it will
still be equivalent to the status quo with the difference that the
developers are not stopped by the release. If we don't get *any* release
out after all of these projects have been added to trunk, then my
proposal is not right for this project. But we won't find out if we
don't try.
Open source is like free flowing water. When a need becomes big enough,
somebody will feel the itch and scratch it. And if nobody feels the itch
- or not enough to put in the energy/time that it takes to scratch it,
then it is an unimportant itch.
Yuv
Simon Oosthoek
> Hi all,
>
> During a private discussion after LGM Pablo had this idea which I think
> now is the time to implement. Details at
>
> <http://panospace.wordpress.com/2009/07/19/whats-in-a-version-number/>
>
> From now on let's use the major version number (padded to four digits)
> for the year, the minor version number for the month (padded to two
> digits) and the third version number to distinguish snapshots (.0) final
> (.1) and bug fixes (>.2)?
>
> so Hugin 0.8.0 becomes Hugin 2009.07.1
>
> If there is no opposition to this suggestion we shall move quickly to
> make the changes in SVN and release 2009.07.1 before new features make
> the trunk unstable again.
>
> future snapshots become Hugin YYYY.MM.0.SVN
>
Hi Yuv,
just to chime in my (remote) opinion, I think a date in snapshot
versions makes sense, as well as the svn sequence number. For a public
release (and release candidates), I'm quite certain that continuing the
existing versioning system will be the most convenient thing for just
about anyone on the receiving end of hugin.
Obviously, if hugin is considered to be 1.x.x material, the major
version should be updated to reflect this. But otherwise, I don't think
any change is warranted and can only confuse some people.
Just my 2 eurocents on the matter...
/Simon
Bruno Postle
>releases are for the general public. snapshots are for "those who know
>what they are doing". Requiring snapshot users to do 'pinning' does not
>seem excessive to me.
'Pinning' is 'hacking around with your system configuration to deal
with broken packages', it shouldn't be a normal part of the Linux
experience for anyone.
>A seamless upgrade is always wishful.
No it isn't, packaging is how you update a Linux system to the
latest distribution year after year and still have it as stable as a
clean install.
--
Bruno
Bruno Postle
>
>Can we agree on:
>V_MAJOR: YYYY
>V_MINOR: sequential, odd for development. and even for stable.
>V_PATCH: for bugfixes on releases
>* right now we'd be 2009.1 in trunk
>* the next release, with nona-gpu, will hopefully be 2009.2; or it will
>be 2010.0
>* after the next release trunk will be bumped to 2009.3 or 2010.1
>respectively
Ok, this suits a system of branching for a stable release. So:
Current trunk becomes 2009.1.0 immediately.
Next stable branch is 2009.2.0 as soon as it branches, trunk becomes
2009.3.0 at the same time.
Final stable release is 2009.2.0. A bugfixes to this release are
2009.2.1, 2009.2.2 etc...
--
Bruno
Yuval Levy
> On Thu 23-Jul-2009 at 09:09 -0400, Yuval Levy wrote:
>> Can we agree on:
>> V_MAJOR: YYYY
>> V_MINOR: sequential, odd for development. and even for stable.
>> V_PATCH: for bugfixes on releases
>
>> * right now we'd be 2009.1 in trunk
>> * the next release, with nona-gpu, will hopefully be 2009.2; or it will
>> be 2010.0
>> * after the next release trunk will be bumped to 2009.3 or 2010.1
>> respectively
>
> Ok, this suits a system of branching for a stable release. So:
>
> Current trunk becomes 2009.1.0 immediately.
means no freezes on trunk, ever?
>
> Next stable branch is 2009.2.0 as soon as it branches, trunk becomes
> 2009.3.0 at the same time.
Just to make sure we're on the same page: the branch becomes 2009.2.0
*before* it is actually stabilized? (see the attached image that depicts
how I envision the interface between the development and release cycles)?
If the next release branch is 2009.2.0 when it is branched, how are
snapshots (alphas), betas, candidates distinguished from final?
I want trunk to keep on living without any freeze.
Note that in the mockup timeline attached I've also depicted a "botched
release scenario": a first attempt is made to release 2010.4.0. After
two snapshots progress stalls, for whatever reason (e.g. those with the
necessary skills decide to allocate their time differently). When later
on somebody picks up the task again, trunk has moved so much forward
that it was better to branch again from trunk rather than updating the
existing / stale codeline.
in the image, each square would be a tag.
> Final stable release is 2009.2.0. A bugfixes to this release are
> 2009.2.1, 2009.2.2 etc...
>
so the full release cycle would go:
the release cycle would then go as:
1. at the start of the release cycle, branch out a new release-codeline,
e.g.
$ svn copy https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/releases/2009.2
-m "Branching 2009.2 for release"
2. in the new release-codeline bump up the version number, e.g.
$ svn co
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/releases/2009.2
2009.2
$ cd 2009.2
edit CMakeLists.txt and commit
# version
set(V_MAJOR 2009)
set(V_MINOR 2)
set(V_PATCH 0)
$ svn ci
3. in trunk bump up the new version number, e.g
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/trunk trunk
$ cd trunk
edit CMakeLists.txt and commit
# version
set(V_MAJOR 2009)
set(V_MINOR 3)
set(V_PATCH 0)
$ svn ci
4. tag the current revision of the new release-codeline for release
(snapshot)
$ svn copy
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/releases/2009.2
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/tags/snapshot-2009.2.0.YYMMDD
-m "Branching 2009.2 for snapshot"
5. package and release snapshot
6. polish the releases/2009.2 codeline and repeat 4 and 5 as often as
necessary.
7. as the quality of the release improves, move the label from snapshot
to alpha, to beta, to candidate, to final.
8. once final, port the relevant "polish" commits to trunk (similar to
merging a development codeline).
9. if patches are required, apply them to /releases/2009.2, bump up
V_PATCH, tag, release.
there is no reason to build/distribute packages from trunk.
Yuv
Bruno Postle
>>
>> Current trunk becomes 2009.1.0 immediately.
>
>means no freezes on trunk, ever?
That's the point of stabilising releases on branches.
>> Next stable branch is 2009.2.0 as soon as it branches, trunk becomes
>> 2009.3.0 at the same time.
>
>Just to make sure we're on the same page: the branch becomes 2009.2.0
>*before* it is actually stabilized? (see the attached image that depicts
>how I envision the interface between the development and release cycles)?
Yes, there is no need to create new version numbers between branch
points.
>If the next release branch is 2009.2.0 when it is branched, how are
>snapshots (alphas), betas, candidates distinguished from final?
The tarball created by cmake is called hugin-2009.2.0.tar.gz, it
coincidentally contains a folder called hugin-2009.2.0
For a release candidate you only want to rename that tarball to
hugin-2009.2.0_rc1.tar.gz but internally it is unchanged. If you
decide to make it the final release, just rename it back again and
reupload.
It makes sense to do beta releases the same way, just put _beta1 in
the tarball filename before uploading it.
>4. tag the current revision of the new release-codeline for release
>(snapshot)
>
>$ svn copy
>https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/releases/2009.2
>https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/tags/snapshot-2009.2.0.YYMMDD
>-m "Branching 2009.2 for snapshot"
>5. package and release snapshot
I wouldn't bother with the 'tag' since the svn number serves the
same purpose, but if you do tag it needs to be the other way around:
4. create snapshot tarball, note svn number.
4a. build tarball to make sure it isn't broken at a basic level.
5. rename and release tarball snapshot.
5a. `svn copy -r 1234 ...` to create a tag for future reference.
Don't put the date in the tag name as this is easy to determine, use
the alpha/beta/rc name as this is what people will use.
>there is no reason to build/distribute packages from trunk.
No need for them to be on sourceforge, but if there was the
procedure would be the same.
--
Bruno
Yuval Levy
> On Fri 31-Jul-2009 at 23:31 -0400, Yuval Levy wrote:
>> no freezes on trunk, ever?
>
> That's the point of stabilising releases on branches.
excellent, we have a deal!
I started to clean up branches/ by creating releases/ and moving out
there the releases
>>> Next stable branch is 2009.2.0 as soon as it branches, trunk becomes
>>> 2009.3.0 at the same time.
>> Just to make sure we're on the same page: the branch becomes 2009.2.0
>> *before* it is actually stabilized? (see the attached image that depicts
>> how I envision the interface between the development and release cycles)?
>
> Yes, there is no need to create new version numbers between branch
> points.
ok. I am currently running some tests. If they are successfull I will
merge nona-gpu into trunk. Right after that I will branch out 2009.2.0
> For a release candidate you only want to rename that tarball to
> hugin-2009.2.0_rc1.tar.gz but internally it is unchanged. If you
> decide to make it the final release, just rename it back again and
> reupload.
>
> It makes sense to do beta releases the same way, just put _beta1 in
> the tarball filename before uploading it.
thanks for explaining how to do this.
>> 4. tag the current revision of the new release-codeline for release
>> (snapshot)
>>
>> $ svn copy
>> https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/releases/2009.2
>> https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/tags/snapshot-2009.2.0.YYMMDD
>> -m "Branching 2009.2 for snapshot"
>
>> 5. package and release snapshot
>
> I wouldn't bother with the 'tag' since the svn number serves the
> same purpose, but if you do tag it needs to be the other way around:
not really. it's svn number + codeline. each codeline exists at a
specific svn number, so we'd have to specify /releases/2009.2 @ SVN. A
tag is a convenience operation.
>
> 4. create snapshot tarball, note svn number.
>
> 4a. build tarball to make sure it isn't broken at a basic level.
>
> 5. rename and release tarball snapshot.
>
> 5a. `svn copy -r 1234 ...` to create a tag for future reference.
> Don't put the date in the tag name as this is easy to determine, use
> the alpha/beta/rc name as this is what people will use.
OK. With tagging, your way.
Yuv