...
| View file | ||||
|---|---|---|---|---|
|
Minutes
- possible topics presentation on the slides
- Release naming
several possibilities- Guillaume Lambert Guillaume: release number rather than periodic (lighty style)
- Robert Varga : ubuntu style with year number - for SR, just an increment x.1, x.2, etc (Casey Cain +1 Cedric Ollivier +1)
- Olivier Dugeon : Release version vs Project version : Nexus to take into account, version difficult to know which version package - tag the package with the release
- Robert : technical difficulties for this, historically we have to abandon this idea. No sure how to fix this concern.
- Olivier: in that case, it must be easier to use the release number. Each project package has its own revision.
- Not all projects follow OpenDaylight numbering. Maintain a list of correspondence or align every project to OpenDaylight version.
- Robert: we need to separate technical versioning vs semantic versioning.
- Cedric Ollivier : we shoudn't roll projects without any change to please the project release name (see a few OPNFV projects) - Release version vs Project versions
first topic: release naming (Robert) - not clear today
- Olivier: we need release notes that identifies these releases
Robert : rather an automatic JIRA issue filler - there is a plugin to fill ReadTheDocs with JIRA but we did not manage to make it work. (link with Navid's topic)
Action Point:
Cedric Ollivier :- we should be independant as much as possible from the bug tracking system
- the workflow can be deduced from git history and automatically manages the JIRA status (Partially closed, closed, etc.)
- Robert: the problem is in the link between the bug tracking system and the documentation - We agree to disagree (Cedric Ollivier yes + best practices vs existing).
- Cedric Ollivier : to deep dive into the link between the bug tracking system and the documentation
...