![[RTEMS Logo]](/images/logo.png){kind=logo}
#2940 closed defect (fixed)
rtems-docs output and catalogue.xml verison numbering is wrong.
| Reported by: | Chris Johns | Owned by: | Chris Johns |
|---|---|---|---|
| Priority: | high | Milestone: | 4.11.2 |
| Component: | doc | Version: | 4.11 |
| Severity: | major | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
The version number management in rtems-docs.git is mixed up and it is not possible to embed a suitable release number in the release build of the documentation.
Remove the version and release from each doc's conf.py and move it into the common/waf.py support.
Provide a command line option --release to specify the release string.
Default the version to the branch number, eg 4.11 (branch).
Change History (5)
comment:1 follow-up: 4 Changed on 03/17/17 at 12:42:42 by Amar Takhar
comment:2 Changed on 03/17/17 at 12:42:52 by Amar Takhar
I forgot to add, what problem are you trying to solve?
comment:3 Changed on 03/20/17 at 04:00:51 by Chris Johns <chrisj@…>
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
In [changeset:"81276042d235328168d75c6a736a9882244e8286/rtems-docs" 8127604/rtems-docs]:
comment:4 Changed on 03/20/17 at 04:01:30 by Chris Johns
Replying to Amar Takhar:
Can you elaborate what's wrong with it? The version number is supposed to be in conf.py. No changeable information should ever be in common/* this is why it is called *common*.
The version numbers in 4.11.1 are 4.11.0 which is wrong. There are no version numbers in common and none are being added.
The --release option is a bad idea, what should happen is the version is changed to the next release then tagged, after that the version is again bumped to the next version. A commandline option would allow for a version existing outside of the repo that doesn't exist in the repo that's very bad for documentation since people keep it around forever. It's like someone saying they have docs for 4.13 but no rtems 4.13 release exists in rtems-docs.
Yes an option is a bad idea, I verbalized a need I had to generate a catalogue for 4.11.1 because that release does not have one and I wanted to avoid adding a 3rd type of doc packaging. I currently have legacy which is pre-ReST and what we have now which contains a catalogue.
I think bumping the release to the next in the repo is a bad idea because any docs generated on that branch will have a real release number and once a release is made you cannot distinguish between a build before the release and release. I am not a fan of odd/evening numbering or special encoding in version numbers to mean special things.
The 4.11 branch version will always be '4.11 (branch)' and I will handle the release labeling in the release procedure.
comment:5 Changed on 10/10/17 at 06:06:29 by Sebastian Huber
| Component: | Documentation → doc |
|---|
Can you elaborate what's wrong with it? The version number is supposed to be in conf.py. No changeable information should ever be in common/* this is why it is called *common*.
The --release option is a bad idea, what should happen is the version is changed to the next release then tagged, after that the version is again bumped to the next version. A commandline option would allow for a version existing outside of the repo that doesn't exist in the repo that's very bad for documentation since people keep it around forever. It's like someone saying they have docs for 4.13 but no rtems 4.13 release exists in rtems-docs.