On the topic of release version numbering
Marq Schneider
chosen (AOL 9.0!!!). Some just increment at each change (btpd more or
less falls in this category). Others have milestone meanings (start
with 0.0.0, bugfix += x.x.1, minor milestone += x.1.x, major milestone
+= 1.x.x). While others yet have meaning regarding APIs (no API
modifications += x.x.1, new API additions += x.1.x, breakage of API +=
1.x.x).
Milestone versioning is geared more toward users and API versioning is
geared toward developers. While i can see going either with milestone
or API, i think i would prefer the API method. Going with API would
allow external tools to be able to clearly identify if the API has
changed. I would be interested in hearing your opinions though.
Regardless of which way we go, my plan is to perform the following:
1. Make the next release 0.16 since this is basically 0.15 with
bugfixes and a couple enhancements
2. Decide on a release process and designate the following release to
be 1.0.0. This will be the first release under the new version
numbering.
3. Follow the version number rules decided for subsequent releases
Questions? Thoughts? Concerns?
-Marq
_______________________________________________
btpd-users mailing list
btpd-...@murmeldjur.se
http://lists.stargirl.org/listinfo/btpd-users
Nicholas Marriott
and bug fix numbering tends to encourage too much effort to be wasted on
backporting trivial bug fixes.
who has time to maintain old releases? it just holds things up and makes
developers bored. on a small project you want development and testing
and (importantly) documentation focus to be as close to the latest
version as possible.
most people can figure out how to use a VCS and for a project with few
dependencies, asking people who hit bugs to checkout and run the latest
git is not a big burden. and it gets it tested for the next release :-).
i usually drop the third number and just do a.b, incrementing b every
release until it hits 9 then going to (b + 1).0. if i need a bug fix
release (very rare and only if it is seriously critical, ie a security
problem or it cores when doing something that can't be avoided) i do eg
0.3a.
with a release every month or so (i tend to release when i have
something to release and if the project is alive 1-2 months tends to be
enough to have a good few changes) this keep version numbers in the
vaguely sane and meaningful range (eg after 2 years you'd expect the
project to be in the 1.5-3.0 range). releasing much more often makes
people confused and makes both users and packagers (who tend to have
lots to do) skip versions.
i have enough problems with people running old versions of ubuntu using
releases from 5 versions ago, let alone if i had 20 releases in the
time to worry about...
or if you want a third number, i would make it mostly zero, so most
releases are a.b.0, a.(b + 1).0 etc except in the rare cases you need a
bug fix release then you do a.b.1.
generally, do what you like, but do please avoid the awful -alpha, -beta,
-rc1, -rc2, -rc3 nonsense :-).
if you are doing shared libraries, then it is important that their major
and minor reflect ABI (not just API!) changes, but there is no reason
that version has to be tied to the main package version and in projects
with mixed shared libraries/binaries it is sometimes hard to achieve
that anyway (you end up with either bumps or releases you don't need).
Florian Stinglmayr
improve the version X of the software. Should bigger changes come
along that completely change how the software works or even break API
increase X. Then perhaps keep branches (or however git calls them) of
each X so in case we would like to fix an important bug in an given
release.
And I always tend to use 0.Y for versions that are not yet ready for a
release. Because some important feature is missing or, documentation
is not yet good enough; etc. etc. Then once 1.0 goes live, new
features are being added and bugs are being fixed steadily increasing
Y. And should all those changes become too hackish; and major rewrites
happen I'd increase X.
I personally just don't want to have an excessive amount of branches
for all sorts of X.Y.Z variants and then have a real hard time getting
bug fixes into each and every one of them. It just makes people bored.
my €0.02
Regards,
Florian
Jonathan Dugan
In the case of BTPD, stable running over long periods of time is a
critical priority of the product.
The only other consideration on numbering I want to see is a
reflection of reliable stability, and the process we have in place
to ensure stability before release.
Even with an excellent testing framework, and with early testing
before releases, all feature additions have the expectation and high
probability to reduce stability in some way.
I'd like to see us have a process for ensuring stability of releases
that includes clear divisions into (for example):
A (feature additions and unit tests creation/iterative dev) -> (HEAD)
B (users in the wild/early feedback) -> latest stable feature set, numbered
C (stable release) -> stable B after X months or Y torrent*users*hours
Whatever we come up with for A->B->C -like processes used to release
the code, or whatever we call them, I feel strongly that having the
numbering reflect the process makes things a lot clearer.
For example, I think calling the next release 1.0 is not the best way
to do it. We take the existing patches, do a quick set of tests, and
call it 0.9 (basically put it into "B"), and get the existing possible
users on this list to production test as hard as possible. No new
feature additions then go into "B" - only bugfixes and stability
improvements. After we have clear evidence that "B" is stable, we
only then call that 1.0. Concurrent to this, we put all the new
features and development into the repo, and once we get to a feature
milestone, we call it 1.1, package/tag it and it becomes "B". This
process will give us the familiar "odds are development, evens are
stable".
If we have any emergencies, security issues, melting down some ISP
from a runaway network issue, we can then issue 0.9.1 or 0.9.2, etc.
Regards,
Jonathan
On Fri, Jul 23, 2010 at 12:38:03AM -0500, Marq Schneider wrote:
Marq Schneider
---
This is good to see several different viewpoints. Allow me to
summarize your thoughts thus far to ensure i understand and provide a
succinct overview.
Nicholas:
Just to x.y. Pretend y is a single decimal digit and when it reaches
10, increment x and set y to 0. Potentially have a x.y.z if quick
bugfixes ever need to be rolled out. Don't tie version numbers with
future library versions.
Florian:
Similar to Nicholas, except no decimal assumption. Start with 0.y (as
btpd has been). Roll 1.0 when all features implemented (milestone
version numbering). Increment x as major rewrites occur.
Jonathan:
Version numbers should reflect stability. Use the "odd version =
development, even = stable" approach. Release 0.16 = stable. Work on
0.17. If critical bugs arise in 0.16, fix there and release 0.16.1.
Once 0.17 achieves stability, release 0.18.
Marq:
As a developer, the idea of version numbers based on API appeals to
me. It makes it clear what changes when and what changes i can expect
other developers to deal with.
So, those are the ideas right now. I can see that i am in the
minority with API version numbering. This is probably because btpd
doesn't have a formal API yet and even if it did, it seems arbitrary
to the user (User: "OMG, 2.0 is released!!!11!! Oh, it's just an API
change...").
That leaves milestone version number with or without dev/stable
release numbers. Honestly, i don't really see development being done
much in the dev/stable fashion. With so few developers working on the
project, i see the git master branch being the 'dev' branch and the
tagged releases being the 'stable' branch. However, we could still
release under the dev/stable paradigm, but just use the even numbers
for now: 0.16, 0.18, 0.20, 1.0, 1.2, etc. in order to allow us to
transition in the future if we see the need.
-Marq
Marq Schneider
-Marq
Nicholas Marriott
can be the latest git. Having multiple development releases just dilutes
testing.
I think skipping version numbers just in case they are needed later is
unnecessarily confusing.
Saying that, I don't think users (or even most developers) either do
care or should have to care about how the versioning works, it is just a
tag for a set of features, so long as it increases in some way and it is
clear what is in each release, it doesn't matter too much. Better to
keep it simple but if you end up with a few people running a dev version
when they meant to run stable, who cares?
On Sat, Jul 31, 2010 at 10:10:23PM -0500, Marq Schneider wrote:
> Oops. I hit "reply" and forgot to switch over to the new mailing list.
> ---
>
> This is good to see several different viewpoints. ?Allow me to
> summarize your thoughts thus far to ensure i understand and provide a
> succinct overview.
>
> Nicholas:
> Just to x.y. ?Pretend y is a single decimal digit and when it reaches
> 10, increment x and set y to 0. Potentially have a x.y.z if quick
> bugfixes ever need to be rolled out. ?Don't tie version numbers with
> future library versions.
>
> Florian:
> Similar to Nicholas, except no decimal assumption. ?Start with 0.y (as
> btpd has been). ?Roll 1.0 when all features implemented (milestone
> version numbering). ?Increment x as major rewrites occur.
>
> Jonathan:
> Version numbers should reflect stability. ?Use the "odd version =
> development, even = stable" approach. ?Release 0.16 = stable. ?Work on
> 0.17. ?If critical bugs arise in 0.16, fix there and release 0.16.1.
> Once 0.17 achieves stability, release 0.18.
>
> Marq:
> As a developer, the idea of version numbers based on API appeals to
> me. ?It makes it clear what changes when and what changes i can expect
> other developers to deal with.
>
> So, those are the ideas right now. ?I can see that i am in the
> minority with API version numbering. ?This is probably because btpd
> doesn't have a formal API yet and even if it did, it seems arbitrary
> to the user (User: "OMG, 2.0 is released!!!11!! ?Oh, it's just an API
> change...").
>
> That leaves milestone version number with or without dev/stable
> release numbers. ?Honestly, i don't really see development being done
> much in the dev/stable fashion. ?With so few developers working on the
> project, i see the git master branch being the 'dev' branch and the
> tagged releases being the 'stable' branch. ?However, we could still