numbering and codename schema
Konopelko, Pavel (P.)
pkonopel at visteon.com
Wed May 11 06:36:06 EDT 2016
Agustin Benito Bethencourt wrote on 2016-05-10:
> ++ Requirements: numbering schema
> The numbering schema needs:
> * To be easy to digest for consumer perspective.
> * To fit the technical requirements from those who develop/deliver GDP.
> * To be coherent with GENIVI's marketing and portfolio strategies.
> In addition to the above, due to the Open Source nature of the project
> the numbering schema should:
> * Be as standard as possible.
> * Be easy to explain and follow for new contributors.
> I would personally add that the numbering schema should include some
> kind of id or fun meaning behind it. Motivation is a key factor in Open
> Requirements: codename schema
> The first question that needs to be solved is if we want to use
> codenames and what for. The second question is, if we do, do we want to
> go for:
> * a fixed codename schema, so is the code associated to the codename
> what changes
> * a variable codename schema, so the code is linked to the codename.
> Another important question to answer is if the codename will be a pure
> "internal" topic or it will have some impact in consumers.
> In any case, the codename schema should be:
> * Unique and simple.
> * Easy to associate to the code and project.
> * Sticky, if it is meant to be used.
> Some might say that, as the numbering, needs to be systematic. I do not
> see this as important as the previous requirements.
I would add to the above the requirement that the GDP version numbering scheme should be related to that of the GENIVI Software Platform (as specified in the compliance specification and implemented by the baselines--such as meta-ivi).
The rationale is that one of the GDP goals (at least as far as I could tell) is to be a demo system built /on top/ of and making use of the GENIVI software platform. Personally, I would even suggest that GDP must be formally compliant.
If we agree on the above, it would make sense (1) to synchronize the GDP release cadence with that of the compliance specification / baselines and (2) to derive the GDP version numbers/names from the compliance specification.
For example, adopt bi-yearly release schedule for GDP and ensure that GDP_major == Compliance_major && GDP_minor >= Compliance_minor within a release cycle. (This would be similar to the current approach for keeping component specification and reference implementation version numbers in synch .) The GDP codenames can be either adopted from the compliance releases (Leviathan, Miranda and friends) or synchronized on the first letter.
>  Wikipedia: https://en.wikipedia.org/wiki/Software_versioning
>  Semantic Versioning: http://semver.org/
>  How to create version numbers that are actually semantic:
More information about the genivi-projects