numbering and codename schema
Konopelko, Pavel (P.)
pkonopel at visteon.com
Wed May 18 10:35:06 EDT 2016
Agustin Benito Bethencourt wrote on 2016-05-16:
> On 11/05/16 12:36, Konopelko, Pavel (P.) wrote:
>> 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 Source.
>>> 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.
> And the other one is to bring innovation.
[In the reasoning below it is being assumed that developing and maintaining a shared software platform (as currently specified by the compliance specification) is still high on the GENIVI Alliance priority list.]
I see only one potential conflict between innovation and formal compliance. Namely, any new components that aim at replacing/refining the functionality that is already implemented by the current software platform (as defined in the compliance specification) cannot be compliant by definition. Another possibility is that new components merely extend the scope of the current GENIVI software platform, in which case there is no conflict.
My solution to the experimental components that should replace existing ones in the compliance would be to put them into a separate place within GDP. A dedicated layer like "meta-ivi-experimental" (or like other people proposed "meta-ivi-next") could be such a place. With that, the part of GDP including all components that do not conflict with the compliance would be reviewed and certified as compliant. The rest (in "meta-ivi-experimental") would be explicitly excluded.
> The question is, can we bring innovation with the current meta-ivi
> cadence/speed or should we go towards a model in which GDP include
> "meta-ivi next"?
The cadence of meta-ivi being twice a year seems to be fast enough to me. The speed (in the sense of how much the compliance hinders the adoption of the bleeding edge software) is another matter. For the most part, the compliance does not prevent from using the latest component implementations (e.g., by requiring a minimum version of certain components).
> GENIVI has stated GDP as the development platform while meta-ivi is our
> compliance/certification "product".
> How do we set up GENIVI's portfolio in a way that the bleeding edge
> product (GDP) feeds the stable one (meta-ivi)? This is a challenge
> derived from the decision of having GDP as the platform for innovation.
What I envision is the following "lifecycle". Offer GDP as a playground for compliance candidates. Make sure that those candidates that conflict with the current status quo are recognizable as such. Once the candidates are mature enough, adopt them in the compliance specification (and move into meta-ivi).
> I, on behalf of Codethink Ltd, proposed a possible solution at the 14th
> AMM. I will detail it a little more and socialise it before presenting
> We are not in a hurry yet since first GDP has to do its homework, which
> is getting at the same level as meta-ivi. I think though that it would
> be good to adapt GENIVI portfolio's design before friction arise. This
> is a discussion that I believe it should take place at technical,
> product/portfolio (management) and exec level.
Looking forward to more details.
>> 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.
> I do not. But we still can synchronise the numbering for some time. I
> will send today another mail to discuss the number and codename we will
> use in GDP.
What specifically are you disagreeing with?
>> 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.
> My proposal goes in the opposite direction of this one. Please check the
> slides of my talk on Tuesday (Members Only day). I do not know any Open
> Source platform or distribution targeting developers with a two year
> release cycle.
GENIVI compliance is released twice a year. (English language seems to use "bi-yearly" for both "once in two years" and "twice a year" --my apologies for the ambiguity.)
>>>  Wikipedia: https://en.wikipedia.org/wiki/Software_versioning 
>>> Semantic Versioning: http://semver.org/  How to create version
>>> numbers that are actually semantic:
>>> Numbers- that-are-Actually-Se
More information about the genivi-projects