ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Community Software Release Announcements - Guideline

release

#1

About

Do you have a new release or update you’d like to announce or are you just interested in keeping track of what is new and shiny? This guideline is to help provide us (the community) with a convention that will make this easier.

Announcing

  • Post in the General Category
  • Add the tag release

An announcement thread should be focused on pointing people at the right places to get them started.

Both source and binary (e.g. OSRF build farm) release announcements are encouraged. Provide a small introduction, some indicator of its status, pointers to links showing how people can get started with your release. You might also like to mention what you’re looking for as well - e.g. are you looking for collaboration or use cases to help drive some experimental design or feedback to decide whether there’s interest enough to support a source release as a binary release? This can help users more readily align with you.

It should not contain documentation or instructions, point to links elsewhere.

It should not be a forum for technical questions, redirect these to issue trackers, ros answers or similar.

Tracking

If you do not wish to track the high volume general category itself, simply set your preferences to follow the release tag.

Browsing

You can browse all previously release announcements by searching for the release tag.


Looking forward to hearing about your latest and greatest!


This is a culmination of the discussions in this thread in which it was recognised that alot of great software was being written in the community, but these were not readily being found.


ROS Live - March 2017 - Package Documentation and Discovery
#2

Minor update suggestion; can we mention about package update, not just new release, in this guideline? I guess we don’t want separate categories per new and update release announcement respectively.


#3

Good point, modified the original post.


#4

Maybe there will be some confusion between these two:

  • “General” category with “release” tag = new package announcements
  • “Release” category = a place for maintainers to communicate about ongoing release issues

#5

Aye, I had the same thought in passing. @tfoote any chance the Release category could adopt a more focused title? e.g. ‘Packaging’? Perhaps the buildfarm category could be merged with it also.


#6

Yeah, the release name does seem to conflict. The main audience of the Release category is maintainers. It should be both for maintainers who are making binary releases as well as potentially just from source. So I think it should be more generic than “Packaging”. Something like “Package Maintainers” might make sense but I’d rather not name the category after the audience.

The buildfarm is a separate audience of people who are deploying the buildfarm.


#7

Hard to get away from the keyword “Release” for that category. After reading the guidelines and posts, It fits. As you say, it’s not only about packaging. How about ‘Packaging & Releasing’ or ‘Release Management’? That narrows the title’s scope at least a little.


#8

How about “Release Maintenance” or “Package Maintenance”?


#9

Both are ok. They lessen the confusion with the release tag at least. I would favour “Packaging & Releasing” still - covers both topics and is a common title for guides discussing how to handle the business end of software development. At least that is what I understand this category is about.


#10

For maintaining links I’d like to keep the shortname /c/release but since there’s no need for the full names to be short. How about: “Release management and package maintenance”

PS I’m also going to recategorize this thread to the Site Feedback category since it’s a meta discussion about use of the site.


#11

I think “Release management and package maintenance” is pretty good, and covers all the bases. However it is pretty wordy, I think “Package and Release Maintenance” gets the point across while being slightly less wordy.


#12

To be pedantic, “Packaging and release maintenance” makes more sense, since it includes building a package and typically maintaining a release means maintaining a package.


#13

Thanks @gbiggs I like that compromise. I’ve updated it but we can change it again if there’s still a better solution. I kept the release key as the short name for backwards compatibility for now.

And @Daniel_Stonier I added most of your copy to the About General topic here.