2026.06.30 Weekly Meeting

Community Weekly meetings
1

Title: 2026.06.30 Weekly Meeting

Next Tuesday, we will be having our next weekly hangout at 10:00 AM ET until 11:00 AM ET.

Anyone is welcome to join at this link: Google Meet meeting

Agenda:

Please post to this thread to put a topic on the agenda! We will try to prioritize agenda items during the meeting.

Thanks
Sam and Ebrahim

2

Notice that we are back to our usual time of 10 AM

3

I’m doublebooked tomorrow, but will join late if I can.

4

Can we potentially discuss abandoning the even/odd versioning scheme especially with the move to Slicer 6 development beginning? It appears that the Linux kernel used to do this and GNOME used to do this, but not anymore. It would be clearer to then have a GitHub milestone for “6.0” containing all the issues planned for the Slicer 6.0 release, rather than having a Slicer “5.13” milestone. Similarly having both a Slicer 5.11 and 5.12 milestone was confusing as it was difficult to know are issues in the 5.11 milestone for the 5.12 release, or are the issues in the 5.12 milestone for the 5.12 release. In general the milestone version is detailing all the issues to complete prior to the stable release of that version.

There has been confusion regarding this even/odd convention for stable releases including most recently as indicated by the following post below, but even by the people I work with as well.

1 Like
5

I agree with not using the preview version #s for milestones, that is confusing.

However, for the nightly build, odd/even version numbering was introduced to reduce confusion about which build was the most recent, which we encountered a lot before we moved to the odd/even version. Would the version number of the preview be the from the previous stable, or the upcoming one? Either way, you end up with this question: which build is newer? Slicer-6.0 or Slicer-6.0-2026-MM-DD? Unless you are aware of the convention ( either previous or upcoming stable number used for the preview), you will be confused.

I am not against changing it, but we would be just trading one confusion for another.

1 Like
6

For myself, I have found that an additional date to the version number would indicate a non-stable release as the stable release never has the date.

So 6.0.0-2026-06-29 would be a preview release prior to an official 6.0.0 release that is date-less. It could go further to something like 6.0.0.dev2026-06-29 or 6.0.0-2026-06-29 (Preview) to make it clearer it is a dev release of some form. I just find that other software generally don’t have a problem with not doing even/odd release pattern while supporting dev/insiders/pre-release releases of their software.

More importantly if there is API breakage as part of the Slicer 6.0 release, it is clearer to the user that the API breakage is expected in a 6.0.0-2026-06-29 version rather than a 5.13.0-2026-06-29 version which would still indicate part of Slicer 5 development.

7

The API breakage argument is highly relevant, given how many of those we are planning, and am fine with making the change. I would just like to reiterate that we changed to even/odd for the 4.8 release specifically because we were getting so many questions about which was the newest version when using the exact versioning method you described.

8

What would be release for the dev track post 6.0.0 stable release?

I am not sure if this is solving anything beyond introducing a new convention. I personally thought the current convention is fairly clear and trivial, but I don’t think it was explicitly documented for people to see it clearly (like in the downloads page). Current text does not mention this at all.

image
image714×566 40.3 KB

1 Like
9
  • 6.0.0.dev2026-06-29 is the development preview period before the 6.0.0 release
  • 6.0.0 is the official stable release
  • 6.1.0.dev2027-03-04would be an example of a development preview period post the 6.0.0 stable release for the 6.1.0 release. This would be what would show when building the main branch after the 6.1.0 tag.
  • 6.0.1.dev2026-11-10 would be an example of a development preview period post the 6.0.0 stable release but for an upcoming 6.0.1 release. This would be how it would show when building say a 6.0 maintenance branch for Slicer.

This is the same versioning convention as using numpy or VTK or python.

Of course knowing what is “newer” is not necessarily relevant when comparing say 6.1.0.dev2026-11-10 from a 6.0.1.dev2026-11-10 as they are 2 different feature release cycles even though they have the same date or even if the 6.0.1 had a newer date. One for the 6.1.0 feature release as part of the main branch and one for a 6.0.1 patch release as part of a 6.0 maintenance branch.

1 Like
10

Adding to agenda the related discussion of the version displayed for preview work within a release branch towards a patch release: ENH: Improve visibility of non-stable release version by jamesobutler · Pull Request #9260 · Slicer/Slicer · GitHub

11

Also adding: Start putting together the 5.12 release announcement

12

Using the odd/even scheme instead of dev suffix is a former VTK convention (that VTK abandoned but Slicer kept). It would be nice to be more standard and use a dev or similar suffix.

However, keeping incrementing the version number for stable releases still makes sense for Slicer for two reasons:

  • in most software projects, installing a more recent version of the software replaces the older one, so the user does not have to manage multiple versions
  • users not just developers, but also users may see preview version numbers (and users have no idea if 6.1.0.dev2027-03-04 or 6.1.0 is more recent)
13

Notes from the meeting:

Versioning scheme

Things everyone seems to agree on:

  • Having just a 6.0 milestone rather than a confusing 5.13 milestone makes sense
  • Writing “(Preview)” or something like that after a preview build to make it clearer that it’s a preview

Less agreement:

  • Whether to keep the even/odd numbering. If we drop it and for example replace 5.13 by something like 6.0.0dev or 6.0.0-preview … people may get confused. Something that sets Slicer apart from other projects that have dropped even/odd is that we normally have a lot of non-developer users who are using the preview version. Users would immediately understand intuitively what is meant by “6.0.0.dev2026-06-29”, and may wonder why has Slicer 6 shown up so early. It is also unintuitive for non-developer users that 5.13 is not something that will ever be released, but at least it is intuitive that it comes after 5.12 and before 6.0.

5.12 release announcement

It is being worked on.