-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare 0.2.0 release #129
Conversation
@rkent I would value your feedback here as well. |
I'm a little nervous about this, because rosdoc2 is not in a particularly stable condition at this point in time. There are still some changes needed to better support the larger projects that have more customization needs. I would hate to have to document the current state, then have a different set of instructions for post 0.2.0 versions. Where will this version end up? If only in rolling, where it can be changed easily before a real release, then this is fine. If the intention is that this current version ends up in some sort of semi-permanent repo, then I would really rather wait a few weeks to get this in a more stable version. I was mostly unavailable in June hence little progress was made. I am mostly unavailable next week (July 15-19), but I am mostly available for the two weeks after that. If this version has any permanent life to it, I would really rather have a couple of weeks to clean things up before release. |
I'll argue that this is the permanent state of things. There are always more things we can do to improve. And saying that rosdoc2 "is not in a particularly stable condition" isn't a fair assessment, I think. The current code is being used daily to generate documentation for thousands of Iron, Jazzy, and Rolling packages. |
What I mean by "not in a particularly stable condition" is that the paths for people to do customizations of rosdoc2 output are not stable at the moment, and in some cases are broken (See #123 for example). I would not recommend to someone with an unusual package configuration to attempt to make rosdoc2 work better for them at the moment, until a few changes are made. Yes things are constantly changing, but at the same time you have code freezes to allow people to stabilize things. Again I ask, how permanent is this proposed release likely to be? In general I am all in favor of specific numbered releases that can be referenced if things change. I'd just like a little warning. |
Happy to answer this question, it's very valid. Infrastructure packages are not bound to specific ROS distributions. Once we make this release, it will be available within the hour in the ROS repositories for all Ubuntu / Debian distributions listed in stdeb.cfg and each future release will go to each of the distros listed in stdeb.cfg at the time of release. We generally support all active distros with a single version of each infrastructure package, so updates to rosdoc2 would continue to support humble for the lifetime of Ubuntu 22.04 / ROS 2 Humble.
Thanks for the context, and for the time you've been dedicating to rosdoc2. I've got this and some README changes staged and that's it for this little sprint. With that in mind and knowing that updates to all stable and forward ROS distros are the expected release process, I'd actually like to push this forward and get an initial version in the repos and that way there's an actual base version out there for the improvements you're brewing to be changelog'd against. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder NOT to squash when merging to preserve the 0.2.0 commit.
3797adf
to
18d87a1
Compare
Although there's a setup.py version designation of 0.1.0, rosdoc2 has never been tagged with a release at this version.
This PR, which on approval I will rebase and fast-forward onto
main
, adds an initial release entry to the changelog at0.2.0
.Once merged I will tag the first commit of this PR as
0.2.0
and publish it to PyPI and the ROS bootstrap repositories then trigger the import to get it into the main ROS repositories.This PR has a second commit, which sets the version to
0.2.1.dev0
which seems to be the appropriate python versioning convention for specifying pre-release as current setuptools freaks out on the semver.org compliantx.y.z-$branch
convention used by ros_buildfarm (PR forthcoming).The build farm builds will continue to use the
main
branch for doc generation for now, but it makes sense to me to switch that over to installing rosdoc2 from apt so that the version used by ROS developers and the build farm can be matched.I consider #128 a pre-requisite for this initial release and this PR will need to be rebased onto it once merged.