Ticket 4221

Summary:	Slurm upgrade support from previous major versions
Product:	Slurm	Reporter:	Ole.H.Nielsen <Ole.H.Nielsen>
Component:	Documentation	Assignee:	Felip Moll <felip.moll>
Status:	RESOLVED FIXED	QA Contact:
Severity:	4 - Minor Issue
Priority:	---	CC:	felip.moll
Version:	17.02.7
Hardware:	Linux
OS:	Linux
Site:	DTU Physics	Alineos Sites:	---
Atos/Eviden Sites:	---	Confidential Site:	---
Coreweave sites:	---	Cray Sites:	---
DS9 clusters:	---	HPCnow Sites:	---
HPE Sites:	---	IBM Sites:	---
NOAA SIte:	---	OCF Sites:	---
Recursion Pharma Sites:	---	SFW Sites:	---
SNIC sites:	---	Linux Distro:	---
Machine Name:		CLE Version:
Version Fixed:	17.02.8	Target Release:	---
DevPrio:	---	Emory-Cloud Sites:	---

Description Ole.H.Nielsen@fysik.dtu.dk 2017-10-04 00:39:24 MDT

The slurm-dev mailing list has a thread about upgrading from old Slurm versions. The documentation page https://slurm.schedmd.com/quickstart_admin.html#upgrade states:

"Slurm daemons will support RPCs and state files from the two previous minor releases (e.g. a version 16.05.x SlurmDBD will support slurmctld daemons and commands with a version of 16.05.x, 15.08.x or 14.11.x)."

I believe the word "minor" is in error and should read "major" (as explained in the ().  Would you kindly edit this word in order to avoid user confusion?

Thanks,
Ole

Comment 1 Felip Moll 2017-10-04 03:26:44 MDT

Hello Ole,

I checked this and the documentation is correct:

16.05.3 is major=16, minor=05, micro=3

Chronological example of releases (where x can be any value from [1-n]):
14.11.x
15.08.x
16.05.x
17.02.x
17.11.x

Two previous minor releases starting on 17.11 are 17.02 and 16.05 despite the fact that from 17.x to 16.x implies a change of major release.

Maybe a better sentence would be just "two previous (non-micro) versions" or "two previous combination of major and minor versions".

The point here is in the time-based release naming schema, we use the first 4 digits as a version and the last digit indicates monthly changes, and we are not using the traditional GNU schema.

We will check the concept internally and update the documentation accordingly.

Thank you,
Felip M

Comment 3 Ole.H.Nielsen@fysik.dtu.dk 2017-10-04 05:22:02 MDT

(In reply to Felip Moll from comment #1)
> Hello Ole,
> 
> I checked this and the documentation is correct:
> 
> 16.05.3 is major=16, minor=05, micro=3
> 
> Chronological example of releases (where x can be any value from [1-n]):
> 14.11.x
> 15.08.x
> 16.05.x
> 17.02.x
> 17.11.x
> 
> Two previous minor releases starting on 17.11 are 17.02 and 16.05 despite
> the fact that from 17.x to 16.x implies a change of major release.
> 
> Maybe a better sentence would be just "two previous (non-micro) versions" or
> "two previous combination of major and minor versions".
> 
> The point here is in the time-based release naming schema, we use the first
> 4 digits as a version and the last digit indicates monthly changes, and we
> are not using the traditional GNU schema.

The documentation's wording "two previous minor releases" is definitely ambiguous.  Perhaps the ambiguity is best resolved by removing the word "minor" in the documentation so it reads "two previous releases".

> We will check the concept internally and update the documentation
> accordingly.

Thanks a lot, every little improvement counts.

/Ole

Comment 7 Felip Moll 2017-10-04 10:26:15 MDT

Hi Ole,

I modified the documentation and it will be available in the next release 17.02.8 and the website will be updated also accordingly.

We removed the "minor" word and kept major as first two digits, so in a 17.02.8 major is 17.02 and micro is 8.

Thank you for your collaboration.

Best Regards.