# 2026.06.30 Weekly Meeting

**URL:** <https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493>\
**Category:** Weekly meetings\
**Created:** [June 29, 2026, 1:13pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493 "2026-06-29T13:13:14Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![ebrahim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ebrahim/32/13403_2.png) [@ebrahim](https://discourse.slicer.org/u/ebrahim)\
**Post date:** [June 29, 2026, 1:13pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/1 "2026-06-29T13:13:14Z")

</div>

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](https://meet.google.com/ymg-ahrz-www)

* * *

> **Weekly Meeting**
>
> **Starts:** June 30, 2026, 10:00am (America/New\_York)\
> **Link:** <https://meet.google.com/ymg-ahrz-www>

**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

---

<div class="post-metadata">

**Author:** ![ebrahim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ebrahim/32/13403_2.png) [@ebrahim](https://discourse.slicer.org/u/ebrahim)\
**Post date:** [June 29, 2026, 1:14pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/2 "2026-06-29T13:14:39Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [June 29, 2026, 3:34pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/3 "2026-06-29T15:34:14Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [June 29, 2026, 4:56pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/4 "2026-06-29T16:56:06Z")

</div>

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.

> [@Release of Slicer 5.12 in progress](https://discourse.slicer.org/t/release-of-slicer-5-12-in-progress/47440/4):
>
> So Slicer 5.11 stable release is skipped? This does look a bit confusing to me:

---

<div class="post-metadata">

**Author:** ![Sam\_Horvath](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/sam_horvath/32/3092_2.png) [@Sam\_Horvath](https://discourse.slicer.org/u/Sam_Horvath)\
**Post date:** [June 29, 2026, 5:08pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/5 "2026-06-29T17:08:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [June 29, 2026, 5:14pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/6 "2026-06-29T17:14:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Sam\_Horvath](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/sam_horvath/32/3092_2.png) [@Sam\_Horvath](https://discourse.slicer.org/u/Sam_Horvath)\
**Post date:** [June 29, 2026, 5:27pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/7 "2026-06-29T17:27:52Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [June 29, 2026, 5:35pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/8 "2026-06-29T17:35:35Z")

</div>

> [@jamesobutler](#):
>
> prior to an official `6.0.0` release that is

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](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/f/8/f814ec65491a286bb3ff54802e0f5098fcd65ef3.png)

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [June 29, 2026, 5:47pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/9 "2026-06-29T17:47:53Z")

</div>

> [@muratmaga](#):
>
> What would be release for the dev track post 6.0.0 stable release?

- `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-04`would 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.

---

<div class="post-metadata">

**Author:** ![ebrahim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ebrahim/32/13403_2.png) [@ebrahim](https://discourse.slicer.org/u/ebrahim)\
**Post date:** [June 30, 2026, 12:27pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/10 "2026-06-30T12:27:21Z")

</div>

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](https://github.com/Slicer/Slicer/pull/9260)

---

<div class="post-metadata">

**Author:** ![ebrahim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ebrahim/32/13403_2.png) [@ebrahim](https://discourse.slicer.org/u/ebrahim)\
**Post date:** [June 30, 2026, 12:39pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/11 "2026-06-30T12:39:34Z")

</div>

Also adding: Start putting together the 5.12 release announcement

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [June 30, 2026, 2:04pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/12 "2026-06-30T14:04:25Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![ebrahim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ebrahim/32/13403_2.png) [@ebrahim](https://discourse.slicer.org/u/ebrahim)\
**Post date:** [June 30, 2026, 5:20pm UTC](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/13 "2026-06-30T17:20:01Z")

</div>

Notes from the meeting:

## Versioning scheme

> [@2026.06.30 Weekly Meeting](https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/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 …

> <https://github.com/Slicer/Slicer/pull/9260>
>
> \> \[!NOTE\]
> \> This is targeting the \`5.12\` release branch
> 
> Related to discussio…n at https://discourse.slicer.org/t/2026-06-30-weekly-meeting/47493/4?u=jamesobutler
> 
> This begins the 5.12.1 development period on the \`5.12\` maintenance branch. This PR results in all commits after the 5.12.0 tagged commit being indicated like:
> "5.12.1-2026-06-29 (Preview)" which indicates a preview build of a future 5.12.1 stable release
> \<img width="383" height="86" alt="image" src="https://github.com/user-attachments/assets/278b517e-da93-4778-ab6d-fd65fd3756e6" /\>
> 
> instead of the current:
> "5.12.0-2026-06-29" which indicates a date of a stable (5.12.0) release version?
> \<img width="379" height="82" alt="image" src="https://github.com/user-attachments/assets/5e5386a7-cdbc-4121-a4d9-f23807b6c2d8" /\>
> 
> 
> The current is a bit confusing as it just seeing that string when running the application it is hard to know if that version came out before the 5.12.0 release or if it came out after the 5.12.0 release. 
> 
> \`ENH: Improve visibility of non-stable release version\` would also be contributed to the \`main\` branch as well if we want to proceed with this improved display of knowing if the version of Slicer being used is a preview release or a stable release.

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.