[jitsi-dev] A discussion about version numbers and SVN revision


#1

Hello all,

We have switched all Jitsi projects to GitHub. Git does not have revision numbers like SVN, but commit hashes instead. So far we've been using the SVN revision number as part of the version and as part of the file name of Jitsi deliverables.

For example, a Jitsi version would look like this:
2.3.4695.9822
where
2.3 is the major version number;
4695 is the CruiseControl (or Jenkins) build number;
9822 is the SVN revision.
Here are several possible solutions:

* using the SVN revision number provided by svn.github.com. We actually tried doing this for a while but had some (potentially resolvable) issues. It also requires use of two separate repositories.

* use the git commit count on master. This works with a single repo.

Both of the above however are a bit of a nonsense because the whole point of introducing rev numbers as part of the version string was to allow developers to easily checkout a version that is being reported as problematic. Better yet, it allowed seeing if a problem that's being reported is occurring with a version that has or does not have a specific fix.

This is no longer that straightforward with the above two bullets. A third option would hence be:

* using the short git hash. This could look awkward in a version string though. It also isn't that simple to determine whether one hash is before or after another one but build numbers could help alleviate this.
Finally we could also just:

* drop the fourth component of the revision.

Opinions are most welcome.

Pavel Tankov


#2

[...]
* using the SVN revision number
* use the git commit count on master. This works with a single repo.
[...]

This is no longer that straightforward with the above two bullets. A third
option would hence be:

* using the short git hash. This could look awkward in a version string
though. It also isn't that simple to determine whether one hash is before

or

after another one but build numbers could help alleviate this.
Finally we could also just:

I thought about this as well, but it would break any tools that assume
version number parts as integers. System Center Configuration Manager is
only one example I use that relies on it. So for me, this is a no-go.

* drop the fourth component of the revision.

Opinions are most welcome.

What about dropping the commit/revision from the version number, but
including the full commit-id in the logs and the about window as an isolated
identification component?

Pavel Tankov

Ingo


#3

Hey guys,

Have you considered using git tags (
http://git-scm.com/book/en/Git-Basics-Tagging) ? We could have a tag for
each build - I suppose they could be automatically created by
CruiseControl/Jenkins - and then to checkout version 2.3.4695 you could
just write `git checkout build4695` or something in the lines.

Cheers,
Ivan

···

On Wed, Jun 26, 2013 at 11:01 AM, Pavel Tankov <ptankov@bluejimp.com> wrote:

Hello all,

We have switched all Jitsi projects to GitHub. Git does not have revision
numbers like SVN, but commit hashes instead. So far we've been using the
SVN revision number as part of the version and as part of the file name of
Jitsi deliverables.

For example, a Jitsi version would look like this:
2.3.4695.9822
where
2.3 is the major version number;
4695 is the CruiseControl (or Jenkins) build number;
9822 is the SVN revision.

Here are several possible solutions:

* using the SVN revision number provided by svn.github.com. We actually
tried doing this for a while but had some (potentially resolvable) issues.
It also requires use of two separate repositories.

* use the git commit count on master. This works with a single repo.

Both of the above however are a bit of a nonsense because the whole point
of introducing rev numbers as part of the version string was to allow
developers to easily checkout a version that is being reported as
problematic. Better yet, it allowed seeing if a problem that's being
reported is occurring with a version that has or does not have a specific
fix.

This is no longer that straightforward with the above two bullets. A third
option would hence be:

* using the short git hash. This could look awkward in a version string
though. It also isn't that simple to determine whether one hash is before
or after another one but build numbers could help alleviate this.
Finally we could also just:

* drop the fourth component of the revision.

Opinions are most welcome.

Pavel Tankov

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

What about dropping the commit/revision from the version number, but including the full commit-id in the logs and the about window as an isolated identification component?

Since the svn revision number is useful for devs to match builds to SVN revisions then this suggestion makes sense. The tools that handle upgrades would still use the cruisecontrol/jenkins build number to compare versions.

Pavel Tankov

···

On 26.юни.2013, at 11:57, Ingo Bauersachs wrote:

[...]
* using the SVN revision number
* use the git commit count on master. This works with a single repo.
[...]

This is no longer that straightforward with the above two bullets. A third
option would hence be:

* using the short git hash. This could look awkward in a version string
though. It also isn't that simple to determine whether one hash is before

or

after another one but build numbers could help alleviate this.
Finally we could also just:

I thought about this as well, but it would break any tools that assume
version number parts as integers. System Center Configuration Manager is
only one example I use that relies on it. So for me, this is a no-go.

* drop the fourth component of the revision.

Opinions are most welcome.

What about dropping the commit/revision from the version number, but
including the full commit-id in the logs and the about window as an isolated
identification component?

Pavel Tankov

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

This is what we’re currently doing at Metaswitch. We use Jenkins for our builds use the following shell fragment to run the build. ($BUILD_NUMBER is filled out automatically by Jenkins)

export MINOR_VERSION=04
ant cc-build-wix -Dlabel=$MINOR_VERSION.$BUILD_NUMBER -DgitSHA=$GIT_COMMIT

if [ $? -ne 0 ]
then
  exit 1
fi

echo $GIT_COMMIT
git tag -a 0.9.$MINOR_VERSION.$BUILD_NUMBER -m "Tagged automatically by Jenkins using the Windows build number"
git push origin 0.9.$MINOR_VERSION.$BUILD_NUMBER

Tom

···

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Ivan Vergiliev
Sent: Wednesday, June 26, 2013 9:14 AM
To: Jitsi Developers
Subject: Re: [jitsi-dev] A discussion about version numbers and SVN revision

Hey guys,

Have you considered using git tags (http://git-scm.com/book/en/Git-Basics-Tagging) ? We could have a tag for each build - I suppose they could be automatically created by CruiseControl/Jenkins - and then to checkout version 2.3.4695 you could just write `git checkout build4695` or something in the lines.

Cheers,
Ivan

On Wed, Jun 26, 2013 at 11:01 AM, Pavel Tankov <ptankov@bluejimp.com<mailto:ptankov@bluejimp.com>> wrote:
Hello all,

We have switched all Jitsi projects to GitHub. Git does not have revision numbers like SVN, but commit hashes instead. So far we've been using the SVN revision number as part of the version and as part of the file name of Jitsi deliverables.

For example, a Jitsi version would look like this:
2.3.4695.9822
where
2.3 is the major version number;
4695 is the CruiseControl (or Jenkins) build number;
9822 is the SVN revision.

Here are several possible solutions:

* using the SVN revision number provided by svn.github.com<http://svn.github.com/>. We actually tried doing this for a while but had some (potentially resolvable) issues. It also requires use of two separate repositories.

* use the git commit count on master. This works with a single repo.

Both of the above however are a bit of a nonsense because the whole point of introducing rev numbers as part of the version string was to allow developers to easily checkout a version that is being reported as problematic. Better yet, it allowed seeing if a problem that's being reported is occurring with a version that has or does not have a specific fix.

This is no longer that straightforward with the above two bullets. A third option would hence be:

* using the short git hash. This could look awkward in a version string though. It also isn't that simple to determine whether one hash is before or after another one but build numbers could help alleviate this.
Finally we could also just:

* drop the fourth component of the revision.

Opinions are most welcome.

Pavel Tankov

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Have you considered using git tags
(http://git-scm.com/book/en/Git-Basics- Tagging) ? We could have a tag
for each build - I suppose they could be automatically created by
CruiseControl/Jenkins - and then to checkout version 2.3.4695 you could
just write `git checkout build4695` or something in the lines.

Hmm. I'm not sure if git tags for the commit-builds (they're not really a nightlies...) are a good idea. We'd have hundreds of tags over time, probably only slightly less than the number of commits.

For future stable builds however, tags are a must.

Cheers,
Ivan

Ingo


#7

Hi,

···

On 6/26/13 11:52 AM, Ingo Bauersachs wrote:

Have you considered using git tags
(http://git-scm.com/book/en/Git-Basics- Tagging) ? We could have a tag
for each build - I suppose they could be automatically created by
CruiseControl/Jenkins - and then to checkout version 2.3.4695 you could
just write `git checkout build4695` or something in the lines.

Hmm. I'm not sure if git tags for the commit-builds (they're not really a nightlies...) are a good idea. We'd have hundreds of tags over time, probably only slightly less than the number of commits.

We could always delete old 'build' tags if they get too many, or have CC/Jenkins maintain only the latest N such tags.

Regards,
Boris


#8

What about dropping the commit/revision from the version number, but including the full commit-id in the logs and the about window as an isolated identification component?

Since the svn revision number is useful for devs to match builds to SVN revisions then this suggestion makes sense.

I'm sorry, but I don't get the meaning of this sentence...

The tools that handle upgrades would still use the cruisecontrol/jenkins build number to compare versions.

I think we all agree to keep the build number as-is.

Ingo


#9

Why would this be a bad thing?

Emil

···

On Wed, Jun 26, 2013 at 10:52 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Have you considered using git tags
(http://git-scm.com/book/en/Git-Basics- Tagging) ? We could have a tag
for each build - I suppose they could be automatically created by
CruiseControl/Jenkins - and then to checkout version 2.3.4695 you could
just write `git checkout build4695` or something in the lines.

Hmm. I'm not sure if git tags for the commit-builds (they're not really a nightlies...) are a good idea. We'd have hundreds of tags over time, probably only slightly less than the number of commits.


#10

It's not necessarily bad, I just feel uneasy about it (which I can't base on any reasoning). It might simply be overkill.

As for Boris' suggestion to remove them after a certain time or number: Not sure now, but I think each change causes a new commit entry in the rev-log.

···

Le 26.06.2013 à 18:43, "Emil Ivov" <emcho@jitsi.org> a écrit :

On Wed, Jun 26, 2013 at 10:52 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Have you considered using git tags
(http://git-scm.com/book/en/Git-Basics- Tagging) ? We could have a tag
for each build - I suppose they could be automatically created by
CruiseControl/Jenkins - and then to checkout version 2.3.4695 you could
just write `git checkout build4695` or something in the lines.

Hmm. I'm not sure if git tags for the commit-builds (they're not really a nightlies...) are a good idea. We'd have hundreds of tags over time, probably only slightly less than the number of commits.

Why would this be a bad thing?


#11

We have years of binaries recorded in Git. We'll be moving to ivy at
some point in the near future (as per your suggestion) but what's done
is done. Comparing tags and ref files to this makes them look rather
insignificant. On the other hand this seems to be the most convenient
way.

Showing a hash tag in the about dialog only resolves part of the
issue. Hashtags however are not something that one can easily
remember, share in a conversation or compare for precedence with other
hashtags.

Emil

···

On Wed, Jun 26, 2013 at 6:51 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Le 26.06.2013 à 18:43, "Emil Ivov" <emcho@jitsi.org> a écrit :

On Wed, Jun 26, 2013 at 10:52 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Have you considered using git tags
(http://git-scm.com/book/en/Git-Basics- Tagging) ? We could have a tag
for each build - I suppose they could be automatically created by
CruiseControl/Jenkins - and then to checkout version 2.3.4695 you could
just write `git checkout build4695` or something in the lines.

Hmm. I'm not sure if git tags for the commit-builds (they're not really a nightlies...) are a good idea. We'd have hundreds of tags over time, probably only slightly less than the number of commits.

Why would this be a bad thing?

It's not necessarily bad, I just feel uneasy about it (which I can't base on any reasoning). It might simply be overkill.

As for Boris' suggestion to remove them after a certain time or number: Not sure now, but I think each change causes a new commit entry in the rev-log.


#12

Have a look at this blog post on one way to handle version numbers and Git:
http://www.hermanradtke.com/blog/blog/canonical-version-numbers-with-git

Feel free to ignore this part of my reply...
On the subject of build automation and dependency management have you
considered Gradle? It is considerably more flexible than Ant and it can
work with Ivy or Maven repositories. It will also work in well with the
Android port once "Android Studio" is released.
http://www.gradle.org/

···

On Wed, Jun 26, 2013 at 1:03 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Wed, Jun 26, 2013 at 6:51 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
> Le 26.06.2013 à 18:43, "Emil Ivov" <emcho@jitsi.org> a écrit :
>
>> On Wed, Jun 26, 2013 at 10:52 AM, Ingo Bauersachs <ingo@jitsi.org> > wrote:
>>>> Have you considered using git tags
>>>> (http://git-scm.com/book/en/Git-Basics- Tagging) ? We could have a
tag
>>>> for each build - I suppose they could be automatically created by
>>>> CruiseControl/Jenkins - and then to checkout version 2.3.4695 you
could
>>>> just write `git checkout build4695` or something in the lines.
>>>
>>> Hmm. I'm not sure if git tags for the commit-builds (they're not
really a nightlies...) are a good idea. We'd have hundreds of tags over
time, probably only slightly less than the number of commits.
>>
>> Why would this be a bad thing?
>
> It's not necessarily bad, I just feel uneasy about it (which I can't
base on any reasoning). It might simply be overkill.
>
> As for Boris' suggestion to remove them after a certain time or number:
Not sure now, but I think each change causes a new commit entry in the
rev-log.

We have years of binaries recorded in Git. We'll be moving to ivy at
some point in the near future (as per your suggestion) but what's done
is done. Comparing tags and ref files to this makes them look rather
insignificant. On the other hand this seems to be the most convenient
way.

Showing a hash tag in the about dialog only resolves part of the
issue. Hashtags however are not something that one can easily
remember, share in a conversation or compare for precedence with other
hashtags.

Emil

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#13

Hey Oliver,

Have a look at this blog post on one way to handle version numbers and Git:
http://www.hermanradtke.com/blog/blog/canonical-version-numbers-with-git

Interesting. How does this work exactly? Is the numeric part incremented by one for every commit? Is it unique or does unicity require using the alpha part too?

Feel free to ignore this part of my reply...
On the subject of build automation and dependency management have you
considered Gradle? It is considerably more flexible than Ant and it can
work with Ivy or Maven repositories. It will also work in well with the
Android port once "Android Studio" is released.
http://www.gradle.org/

Thanks for the pointer. We aren't having any specific issues with and currently, but it's always good to know what's out there in case things changes.

Cheers,
Emil

···

On 26.06.13, 19:38, Oliver Chong wrote:

On Wed, Jun 26, 2013 at 1:03 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    On Wed, Jun 26, 2013 at 6:51 PM, Ingo Bauersachs <ingo@jitsi.org > <mailto:ingo@jitsi.org>> wrote:
     > Le 26.06.2013 à 18:43, "Emil Ivov" <emcho@jitsi.org > <mailto:emcho@jitsi.org>> a écrit :
     >
     >> On Wed, Jun 26, 2013 at 10:52 AM, Ingo Bauersachs > <ingo@jitsi.org <mailto:ingo@jitsi.org>> wrote:
     >>>> Have you considered using git tags
     >>>> (http://git-scm.com/book/en/Git-Basics- Tagging) ? We could
    have a tag
     >>>> for each build - I suppose they could be automatically created by
     >>>> CruiseControl/Jenkins - and then to checkout version 2.3.4695
    you could
     >>>> just write `git checkout build4695` or something in the lines.
     >>>
     >>> Hmm. I'm not sure if git tags for the commit-builds (they're
    not really a nightlies...) are a good idea. We'd have hundreds of
    tags over time, probably only slightly less than the number of commits.
     >>
     >> Why would this be a bad thing?
     >
     > It's not necessarily bad, I just feel uneasy about it (which I
    can't base on any reasoning). It might simply be overkill.
     >
     > As for Boris' suggestion to remove them after a certain time or
    number: Not sure now, but I think each change causes a new commit
    entry in the rev-log.

    We have years of binaries recorded in Git. We'll be moving to ivy at
    some point in the near future (as per your suggestion) but what's done
    is done. Comparing tags and ref files to this makes them look rather
    insignificant. On the other hand this seems to be the most convenient
    way.

    Showing a hash tag in the about dialog only resolves part of the
    issue. Hashtags however are not something that one can easily
    remember, share in a conversation or compare for precedence with other
    hashtags.

    Emil

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org