[syslinux] Module Versioning

[Ady]

> On 02/24/16 20:45, Shao Miller via Syslinux wrote:
> > On 2/24/2016 22:55, Shao Miller wrote:
> >> Suppose...:
> >> - For non-releases: "git" + We take the first 6 chars of git commit
> >> - For releases: "ver" + major + "." + minor
> >> - For tar-balls: Something clever, maybe involving the date
> >>
> >> ...that we embed such a version in Syslinux core and in all OS programs
> >> and modules.  Maybe even with some nearby magic so that a "whichver"
> >> command can examine and answer.
> >>
> >> If we have that, Ady's recent question is: If Syslinux' module-loader
> >> encounters a module without version-info, do we:
> >> - Reject and return
> >> - Warn and continue
> >> - Hope for the best and continue
> >>
> >> ?
> >>
> > 
> > (Or, for the version-field, just use what gen-id.sh produces.)
> > 
> 
> I think we should just use what gen-id.sh produces.  For non-releases we
> really don't need to be too picky.
> 
> 	-hpa
> 
 
 
That's not what common users are forced to deal with. Syslinux's binary 
files in the wild come from different sources (official upstream 
Syslinux, distros' packages, others).

Since v.6+ (and possibly, even before it) a re-build might show some 
inconsistencies between "the same version" of files (bootloader file, 
c32 module, etc.).

A "version" such as "6.03" is not enough.

Some "standard" method for versioning should be officially supported by 
The Syslinux Project, it should be included in official code (e.g. all 
c32 modules currently included in the official code), it should deal 
not only with upstream release versions but also with other cases 
(pre-release, git, dates, distros' packages), and it should cover the 
needs of distros and final users. This is the only way in which every 
new build (including those made by distros and others) might provide a 
chance of a solution for users.

Assuming that users and distros only use upstream released binary files 
would be wishful thinking, not reality.

Additional points: whichever standard versioning method is (hopefully) 
adopted, it should be:

_ flexible enough that it can be expanded according to future needs 
("needs" not just for upstream Syslinux but also for downstream builds 
/ patches); and,

_ it should be clearly documented and publicized.

Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>