Versioning


#1

Hey all,

Now that the 1.0 is out (check this out people! 1.0!) it's probably time
we made sure we have an optimal versioning system that matches our
development and build cycles.

I've been talking to some of you and the main points that I've heard so
far are:

- we currently have a linear build cycle (i.e. we don't branch for every
major release) so we probably don't need a three component version
number. At least not the way it's used conventionally.

- it would be very handy to have the SVN revision as part of the version
(at least for nightly builds) as the build number only gives an indirect
reference to the code that's being discussed in issue reports.

- it's still important to keep the build numbers as they are consecutive
and people can easily relate them to one another and to time in general
(given we have ~1 per day)

So here are the two suggestions that seem to take the above into account:

* V.B.R <version.build.revision>

We basically bump the V every time we make a new stable release. We
possibly also drop the B and the R for these releases and only keep them
for nightlies. This way our next stable will be Jitsi 2, then Jitsi 3,
etc. In between, for the nightlies we'll have Jitsi 1.3999.9976, Jitsi
2.4029.10899

That's kind of what you get with Chrome and Firefox lately.

* V.v.B-R <version-major.version-minor.Bbuild-Rrevision>

Every time we make a release we make the choice of either bumping the
version major or minor depending on how important we judge the changes
in the build (i.e. rather important and disruptive vs. mostly fixes and
relatively minor enhancements).

The B-R label at the end is just a concatenation of the build and
revision numbers and in this case too we could drop them for the stable
releases.

This way our next stable will be either Jitsi 1.1 or Jitsi 2, then Jitsi
1.2 or Jitsi 2.1 or Jitsi 3, etc. In between, for the nightlies we'll
have Jitsi 1.1.b3999r9976 or Jitsi 2.0.b4029r10899 ... or something
along those lines

I believe that this is what Mozilla Thunderbird use although I haven't
really checked into their official policy so I may be wrong.

So, what would you, folks, like to see from now on?

Emil

···

--
http://jitsi.org


#2

Hi all, Emil,

I would vote for the second suggestion. I find it more flexible and it gives us the possibility to come up with stable releases more often by offering just some bug fixes and minor improvements. It would be then easier for the user to recognize a major release from a minor one.

Cheers,
Yana

···

On Apr 2, 2012, at 11:43 PM, Emil Ivov wrote:

Hey all,

Now that the 1.0 is out (check this out people! 1.0!) it's probably time
we made sure we have an optimal versioning system that matches our
development and build cycles.

I've been talking to some of you and the main points that I've heard so
far are:

- we currently have a linear build cycle (i.e. we don't branch for every
major release) so we probably don't need a three component version
number. At least not the way it's used conventionally.

- it would be very handy to have the SVN revision as part of the version
(at least for nightly builds) as the build number only gives an indirect
reference to the code that's being discussed in issue reports.

- it's still important to keep the build numbers as they are consecutive
and people can easily relate them to one another and to time in general
(given we have ~1 per day)

So here are the two suggestions that seem to take the above into account:

* V.B.R <version.build.revision>

We basically bump the V every time we make a new stable release. We
possibly also drop the B and the R for these releases and only keep them
for nightlies. This way our next stable will be Jitsi 2, then Jitsi 3,
etc. In between, for the nightlies we'll have Jitsi 1.3999.9976, Jitsi
2.4029.10899

That's kind of what you get with Chrome and Firefox lately.

* V.v.B-R <version-major.version-minor.Bbuild-Rrevision>

Every time we make a release we make the choice of either bumping the
version major or minor depending on how important we judge the changes
in the build (i.e. rather important and disruptive vs. mostly fixes and
relatively minor enhancements).

The B-R label at the end is just a concatenation of the build and
revision numbers and in this case too we could drop them for the stable
releases.

This way our next stable will be either Jitsi 1.1 or Jitsi 2, then Jitsi
1.2 or Jitsi 2.1 or Jitsi 3, etc. In between, for the nightlies we'll
have Jitsi 1.1.b3999r9976 or Jitsi 2.0.b4029r10899 ... or something
along those lines

I believe that this is what Mozilla Thunderbird use although I haven't
really checked into their official policy so I may be wrong.

So, what would you, folks, like to see from now on?

Emil

--
http://jitsi.org


#3

If it's only between these two, then Variant 2, same arguments as Yana.
However I'd prefer V.v.B.R (B and R without prefixes), so e.g. 1.1.4029.10899. IMO dots are more familiar than prefixes and dashes and less nerdy :slight_smile:

Regards,
Ingo

···

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Montag, 2. April 2012 23:43
To: Jitsi Developers
Subject: [jitsi-dev] Versioning
Hey all,

Now that the 1.0 is out (check this out people! 1.0!) it's probably time
we made sure we have an optimal versioning system that matches our
development and build cycles.

I've been talking to some of you and the main points that I've heard so
far are:

- we currently have a linear build cycle (i.e. we don't branch for every
major release) so we probably don't need a three component version
number. At least not the way it's used conventionally.

- it would be very handy to have the SVN revision as part of the version
(at least for nightly builds) as the build number only gives an indirect
reference to the code that's being discussed in issue reports.

- it's still important to keep the build numbers as they are consecutive
and people can easily relate them to one another and to time in general
(given we have ~1 per day)

So here are the two suggestions that seem to take the above into account:

* V.B.R <version.build.revision>

We basically bump the V every time we make a new stable release. We
possibly also drop the B and the R for these releases and only keep them
for nightlies. This way our next stable will be Jitsi 2, then Jitsi 3,
etc. In between, for the nightlies we'll have Jitsi 1.3999.9976, Jitsi
2.4029.10899

That's kind of what you get with Chrome and Firefox lately.

* V.v.B-R <version-major.version-minor.Bbuild-Rrevision>

Every time we make a release we make the choice of either bumping the
version major or minor depending on how important we judge the changes
in the build (i.e. rather important and disruptive vs. mostly fixes and
relatively minor enhancements).

The B-R label at the end is just a concatenation of the build and
revision numbers and in this case too we could drop them for the stable
releases.

This way our next stable will be either Jitsi 1.1 or Jitsi 2, then Jitsi
1.2 or Jitsi 2.1 or Jitsi 3, etc. In between, for the nightlies we'll
have Jitsi 1.1.b3999r9976 or Jitsi 2.0.b4029r10899 ... or something
along those lines

I believe that this is what Mozilla Thunderbird use although I haven't
really checked into their official policy so I may be wrong.

So, what would you, folks, like to see from now on?

Emil


#4

Hi,

I personnally vote for the second way (V.v.B-R). It is better to update the major version if there are significant changes/features.

Regards,

···

--
Seb

Le 02/04/12 23:43, Emil Ivov a �crit :

Hey all,

Now that the 1.0 is out (check this out people! 1.0!) it's probably time
we made sure we have an optimal versioning system that matches our
development and build cycles.

I've been talking to some of you and the main points that I've heard so
far are:

- we currently have a linear build cycle (i.e. we don't branch for every
major release) so we probably don't need a three component version
number. At least not the way it's used conventionally.

- it would be very handy to have the SVN revision as part of the version
(at least for nightly builds) as the build number only gives an indirect
reference to the code that's being discussed in issue reports.

- it's still important to keep the build numbers as they are consecutive
and people can easily relate them to one another and to time in general
(given we have ~1 per day)

So here are the two suggestions that seem to take the above into account:

* V.B.R<version.build.revision>

We basically bump the V every time we make a new stable release. We
possibly also drop the B and the R for these releases and only keep them
for nightlies. This way our next stable will be Jitsi 2, then Jitsi 3,
etc. In between, for the nightlies we'll have Jitsi 1.3999.9976, Jitsi
2.4029.10899

That's kind of what you get with Chrome and Firefox lately.

* V.v.B-R<version-major.version-minor.Bbuild-Rrevision>

Every time we make a release we make the choice of either bumping the
version major or minor depending on how important we judge the changes
in the build (i.e. rather important and disruptive vs. mostly fixes and
relatively minor enhancements).

The B-R label at the end is just a concatenation of the build and
revision numbers and in this case too we could drop them for the stable
releases.

This way our next stable will be either Jitsi 1.1 or Jitsi 2, then Jitsi
1.2 or Jitsi 2.1 or Jitsi 3, etc. In between, for the nightlies we'll
have Jitsi 1.1.b3999r9976 or Jitsi 2.0.b4029r10899 ... or something
along those lines

I believe that this is what Mozilla Thunderbird use although I haven't
really checked into their official policy so I may be wrong.

So, what would you, folks, like to see from now on?

Emil


#5

Emil Ivov:

Hey all,

Now that the 1.0 is out (check this out people! 1.0!) it's probably time
we made sure we have an optimal versioning system that matches our
development and build cycles.

These are the two most popular versioning principles others are using, IMHO:

http://semver.org
http://kitenet.net/~joey/blog/entry/version_numbers

You might consider a possible future change to another version control system.
And please think about third party builds that want to refer to the version of
a source release, independent of a particular binary build.

Regards,

Thomas Koch, http://www.koch.ro


#6

If it's only between these two, then Variant 2, same arguments as Yana.
However I'd prefer V.v.B.R (B and R without prefixes), so e.g. 1.1.4029.10899.

We can consider this as V2. I didn't really mean for the BR formatting
to be set in stone, so the above is certainly an option.

Emil

···

On 03.04.12 00:20, Bauersachs Ingo wrote:

IMO dots are more familiar than prefixes and dashes and less nerdy :slight_smile:

Regards,
Ingo

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Montag, 2. April 2012 23:43
To: Jitsi Developers
Subject: [jitsi-dev] Versioning
Hey all,

Now that the 1.0 is out (check this out people! 1.0!) it's probably time
we made sure we have an optimal versioning system that matches our
development and build cycles.

I've been talking to some of you and the main points that I've heard so
far are:

- we currently have a linear build cycle (i.e. we don't branch for every
major release) so we probably don't need a three component version
number. At least not the way it's used conventionally.

- it would be very handy to have the SVN revision as part of the version
(at least for nightly builds) as the build number only gives an indirect
reference to the code that's being discussed in issue reports.

- it's still important to keep the build numbers as they are consecutive
and people can easily relate them to one another and to time in general
(given we have ~1 per day)

So here are the two suggestions that seem to take the above into account:

* V.B.R <version.build.revision>

We basically bump the V every time we make a new stable release. We
possibly also drop the B and the R for these releases and only keep them
for nightlies. This way our next stable will be Jitsi 2, then Jitsi 3,
etc. In between, for the nightlies we'll have Jitsi 1.3999.9976, Jitsi
2.4029.10899

That's kind of what you get with Chrome and Firefox lately.

* V.v.B-R <version-major.version-minor.Bbuild-Rrevision>

Every time we make a release we make the choice of either bumping the
version major or minor depending on how important we judge the changes
in the build (i.e. rather important and disruptive vs. mostly fixes and
relatively minor enhancements).

The B-R label at the end is just a concatenation of the build and
revision numbers and in this case too we could drop them for the stable
releases.

This way our next stable will be either Jitsi 1.1 or Jitsi 2, then Jitsi
1.2 or Jitsi 2.1 or Jitsi 3, etc. In between, for the nightlies we'll
have Jitsi 1.1.b3999r9976 or Jitsi 2.0.b4029r10899 ... or something
along those lines

I believe that this is what Mozilla Thunderbird use although I haven't
really checked into their official policy so I may be wrong.

So, what would you, folks, like to see from now on?

Emil

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#7

Hi,

Same as above, I think minor version is important to have it for some
fixes, if needed.
But the 'fixes' word make me think that we are making stable releases
on a month or several months bases and we don't actually do fixes :slight_smile:
And fix means having a branch and fixing in it and merging back to
trunk in order to have only fixes in the released build without the
new things we are currently working on.
So yes variant two is ok, but I think we are not actually using it.
WDYT?

Cheers
damencho

···

On Tue, Apr 3, 2012 at 7:58 AM, Sebastien Vincent <seb@jitsi.org> wrote:

I personnally vote for the second way (V.v.B-R). It is better to update the
major version if there are significant changes/features.


#8

Hey Thomas,

Emil Ivov:

Hey all,

Now that the 1.0 is out (check this out people! 1.0!) it's probably time
we made sure we have an optimal versioning system that matches our
development and build cycles.

These are the two most popular versioning principles others are using, IMHO:

http://semver.org
http://kitenet.net/~joey/blog/entry/version_numbers

Thanks, the point is though that we need this to also fit our own
development cycles.

You might consider a possible future change to another version control system.
And please think about third party builds that want to refer to the version of
a source release, independent of a particular binary build.

Yup that's taken into account with both suggestions. That's what the R
thing is about. Or were you referring to something else?

Emil

···

On 03.04.12 09:53, Thomas Koch wrote:

--
http://jitsi.org