Skip to content
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

Closed
wants to merge 0 commits into from
Closed

Prepare 0.2.0 release #129

wants to merge 0 commits into from

Conversation

nuclearsandwich
Copy link
Contributor

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 at 0.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 compliant x.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.

@nuclearsandwich
Copy link
Contributor Author

@rkent I would value your feedback here as well.

@rkent
Copy link
Contributor

rkent commented Jul 11, 2024

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.

@clalancette
Copy link
Contributor

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.

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.

@rkent
Copy link
Contributor

rkent commented Jul 11, 2024

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.

@nuclearsandwich
Copy link
Contributor Author

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.

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.

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.

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.

Copy link
Member

@cottsay cottsay left a 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.

@nuclearsandwich nuclearsandwich deleted the prepare-0.2.0 branch July 12, 2024 23:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants