--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/ML_1JsHLuF0J.
For more options, visit https://groups.google.com/groups/opt_out.
I didn't add a date or rev for each entry as I figured that was redundant info from the VCS (version number == tag number which in turn maps to hash+date) and didn't want users to have to worry about it. Do you feel there's a reason why it should be added in explicitly?
As for being able to reference issues within each entry inline the way we can on GitHub, we might be able to do some filtering to automatically turn hashes into links. To keep it simple for now, we thought that embedded URIs should be sufficient. Yes you'll have to write out the entire link, but when it's rendered you'll only see the label. Do you think there's a strong enough use case that we should address it now?
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/5ioT0MLoj9MJ.
* You are correct about the RST headings, I can reword that to say we only supported dashed headings.
* I did not mean to imply that the change list was complete RST...rather i was trying to say that it uses a very limited subset of RST.
as you noted the rpm/deb formats are sort of strict so we don't want to deal with issues such as exotic markup mucking them up. Once we're confident things work well, we can slowly loosen the constraints.
* Your proposed alternative sounds reasonable though not as simple as I personally would like. I'd love to hear feedback from others on this approach and if there's strong enough consensus, we can go that route.
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-buildsy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/3YiRkJYuA5QJ.
Hey Thibault,I disagree on the subset qualification...what we have specified IS a subset of RST. If we think in terms of formal languages, the grammar for our restricted subset generates strings that are always members of the the set of strings that the RST grammar can generate.
0.1.1
-----
* |link| test
I think what is being missed is not the syntactic rules of the changelog, but rather one level up at the semantic level (yes I'm thinking in terms of programming languages/compilers). Our changelog grammar (syntax) is a subset of the RST grammar, but our language is more than that as it has semantic constraints that grammar does not cover. For example, we have a restriction that the headings must be version numbers and we want them to be sequential (I did not mention the latter in the spec, but that needs to be added in). It doesn't matter what route you go, you will HAVE to at some point parse some of the log yourself in order to verify its correctness.
If we make the format more complex than it is now and allow full-fledged RST or some other language, then I think we're in for a world of hurt when we need to verify its correctness and extract information out of it.
Changelog for package foo
=========================
0.1
===
0.1.27
^^^^^^
- dash for bullet list
.. rst comment
0.1.26
^^^^^^
+ using + for bullet list, and reference `Python <http://www.python.org/>`_
+ second element *emphasized*
0.1.4
=====
text without bullet list
[(u'0.1.27', [u'dash for bullet list', u'rst comment']),
(u'0.1.26',
[u'using + for bullet list, and reference `Python <http://www.python.org/>`_',
u'second element *emphasized*']),
(u'0.1.4', [u'text without bullet list'])]
Hey Thibault,
Ah yes you are correct regarding the grammar, my apologies. Regarding parsing and verification, correctness is indeed usually checked after parsing though it is often convenient to do some of the higher level stuff while building the abstract syntax tree. I did not look at your code earlier (my bad sorry), I see now that you use docutils to generate the AST (ie parse) and then traversing it to verify it. Yes, I agree now that this is a better solution :)
~mirza
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/XR9Gku_M9pQJ.
Actually, github does not, must have been wishful thinking on my part. But we could invent a rst flavour that does so and suggest it to github. Still for the REP, that means no change, I still don't know how to link issues nicely other than by full url.
1. Item 1 initial text.
a) item1a
b) item1a
2. Item 2
1. Item 2
2. Item 2
* level1 bullet
* level2 bullet
* level2 bullet2
* level3 bullet
* level3 bullet2
1 Item 1 initial text.
_1 item1a
_2 item1a
1 Item 2
_1 Item 2
_2 Item 2
_level2 bullet
_level2 bullet2
__level3 bullet
__level3 bullet2
_level2 bullet3
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/UnY-xJuGUYwJ.
Though I have reservations about reading the README.rst looking for changelog, it seem to conflict with GitHub's standard Readme display being effectively the homepage of the project.
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/bUiPY_XNhWAJ.
On 26 February 2013 20:20, tkruse <tibo...@googlemail.com> wrote:
On Tuesday, February 26, 2013 10:16:00 AM UTC+1, Tully Foote wrote:Though I have reservations about reading the README.rst looking for changelog, it seem to conflict with GitHub's standard Readme display being effectively the homepage of the project.
Can you expand on that? I mentioned this specifically because already on Github many projects use README.rst for their changelog, as you can see if you google "github README.rst changelog". So I see this as compliant with github, not conflicting.
And for projects will a small enough Changelog, I find it reasonable and convenient to get the Changelog on the githb "homepage". And as I put it later in the search preference, if the changelog grows too large it can be placed in a separate file.
Some people do use their github README.rst for other things though. If we can add the changelog feature without constraining what they currently do (even if that group is only a minority), that's always got to be the best course.
----To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/bUiPY_XNhWAJ.
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin R&D: http://rnd.yujinrobot.com/
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsystem+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ros-sig-buildsystem/-/bUiPY_XNhWAJ.
--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin R&D: http://rnd.yujinrobot.com/
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsystem+unsub...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsystem+unsub...@googlegroups.com.
To post to this group, send email to ros-sig-b...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "ROS Buildsystem Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildsy...@googlegroups.com.
Hi Aldolfo,
the idea is that a release system can combine the information from the Changelog with the information from a VCS, to put a date on a version. So if you installed the debian package, you'd get a changelog where version number and date are combined.
http://www.debian.org/doc/debian-policy/ch-source.htmlpackage (version) distribution(s); urgency=urgency [...] -- maintainer name <email address>[two spaces] date package (version) distribution(s); urgency=urgency [...] -- maintainer name <email address>[two spaces] date
The date has the following format:
day-of-week, dd month yyyy hh:mm:ss +zzzz
Based on the feedback we have discussed this topic in our todays meeting and came to the following conclusion:
Headlines with the following format are considered changelog entries:
A version number or a version number followed by a timestamp in parenthesis.A version number is in the form x.y.z as specified in https://github.com/ros-infrastructure/rep/blob/master/rep-0127.rst#version. For REP 132 this is not open for discussion - if different formats should be allowed that should be brought up against REP 127.
The timestamp must contain a full date (YYYY-MM-DD) and might be followed by a time (hh:mm:ss where the seconds are optional) and optionally followed by a time offset (+/-xxxx). The timestamp must be parsable by Python
dateutil.parser.parse
.It is not necessary to allow free form text in the headline since it can be easily placed in other locations, i.e. in its own section or as a part of the sections content.
The implementation will take each headline, separate the version number from the (optional) timestamp and tries to parse both. If that fails the section is not considered to be a changelog entry but free form text.
Some examples what that implies:
A headline1.2.3 (forthcoming)
can be placed in the file, but it is not considered a changelog entry. It appears in the Wiki and provides valuable information to the users. During the release process bloom will uses the API to determine if it contains a changelog entry for version 1.2.3. Since the implementation will not consider that headline a valid changelog entry bloom and warn about a missing changelog entry. The maintainer must either updated the headline to contain a timestamp or remove the annotation.Allow versions without a timestamp has the following sideeffect:
If bloom finds a valid changelog entry without a timestamp it can just usenow()
to satisfy the needs of i.e.e Debian packages. But for the user reading the changelog file in i.e. the Wiki a version number without a timestamp is ambiguous. It could be that this is an upcoming version (where the maintainer did not add an annotation like(forthcoming)
) or it could mean it is a released version (but the maintainer did not provided a timestamp).