[jitsi-users] Jitsi Meet stable releases, now more discoverable!


#1

Hi all,

If you have been following the Jitsi Meet development for some time,
you might have noticed the sheer amount of git tags. We make tags for
every successful build our CI makes, and also every time we "cut a
release".

It was, however, not very easy to keep track of the latest stable
release. No more. We have started making special tags for stable
releases. They look like stable/jitsi_meet_XXX across all projects.

For example:

$ git tag -l stable*
stable/jitsi-meet_2988

In addition, the GitHub release entry has some release highlights, check it out!

Regards
Your Jitsi Team


#2

Hey Damian, this is awesome, thanks!

I’m trying to switch over from the (somewhat arbitrary) builds that I’ve been using, to these tags.

I noticed that the latest stable release to date, https://github.com/jitsi/jitsi-meet/releases/tag/stable/jitsi-meet_3229 corresponds with a version identifier that is 2942. This corresponds to https://download.jitsi.org/jitsi-meet/src/jitsi-meet-1.0.2942.tar.bz2, right? The github page for the release also contains a couple of downloads (The bare source code in git for that version), but that does not equal the bz2 file on download.jitsi.org.

  • What exactly are the differences between the two downloads?
  • Should the bz2 download be added to the list of downloadables in the github page for the release?
  • We’re now using two different four digit numeric identifiers for the same tag. This confuses people (well, me, but I’m people too!) Can we somehow differentiate between the two identifiers (add a small textual identifier, perhaps)?

#3

As an instant-followup question: I noticed that the maven projects (like JVB) got the same stable tag. How can I determine what exact maven version relates to that tag?


#4

So we have a meta package https://github.com/jitsi/jitsi-meet-debian-meta which has fixed versions for the dependencies, so the version jitsi-meet_3229, 3229 is the meta package version and the version 2942 is the jitsi-meet-web version that corresponds the meta version 3229.

Whenever we build a version of jitsi-meet-web, jicofo or jvb there is a new meta-package with the current versions of the components.

There are few scripts in the meta package that can retrieve versions, they are not perfect, but they works and they depend on updated debian repo on the machine you run them.

So the versions for jitsi-meet-web, jicofo and jvb you can find in the corresponding text files there if you checkout the tag there: https://github.com/jitsi/jitsi-meet-debian-meta/tree/jitsi-meet_3229.

The link https://download.jitsi.org/jitsi-meet/src/jitsi-meet-1.0.2942.tar.bz2 is the jitsi-meet-web version 2942.

Hope this clears it a bit, not sure how we can improve that … any suggestions are welcome.


#5

And the tag with the meta version: jitsi-meet_3229 goes to all projects including jitsi-meet-torture to map the versions that are used and when testing that combination and the version of torture used for testing those.


#6

My head spins :slight_smile:
How do I now figure out what Maven version corresponds to each meta package version?


#7

You need to open the pom.xml of that tag and check it.


#8

Apologies for being dense, but: which pom?

https://github.com/jitsi/jitsi-videobridge/blob/stable/jitsi-meet_3229/pom.xml#L14 has a SNAPSHOT version identifier, not a unique numeric one.


#9

Well, yeah you are right, so … only way to match the tags/builds and maven artefacts is checking in jenkins … No idea how we can improve those …


#10

Well, the obvious improvement is using proper versions, not snapshot numeric IDs. I have no idea how much impact it’d have to change from snapshots to proper versions though. That might be considerable.

I never knew the reason for using the snapshot numeric identifiers. Why did we choose to go down that road? Was it simply convenient at the time, or is there more behind it?