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

Release 3.1.5-6 #43

Closed
130s opened this issue Apr 8, 2014 · 8 comments
Closed

Release 3.1.5-6 #43

130s opened this issue Apr 8, 2014 · 8 comments
Assignees

Comments

@130s
Copy link

130s commented Apr 8, 2014

Waiting for start-jsk/openrtm_aist_core#49 to be done.

@130s 130s self-assigned this Apr 8, 2014
@130s
Copy link
Author

130s commented Apr 11, 2014

Now ready to be released. Pre-release job.

@130s
Copy link
Author

130s commented Apr 15, 2014

Pre-release test was unstable probably because some failures occurred in downstream. As similar to what I reported here, it's hard to tell from these failures if there's an issue within the package tested or not because some unit tests in downstream themselves are not stable.

That said I'll release this now.

@130s
Copy link
Author

130s commented Apr 15, 2014

Submitted.

@130s 130s closed this as completed Apr 15, 2014
@130s
Copy link
Author

130s commented Apr 15, 2014

Do Groovy users also need this to be released? Personally because there's a critical error that is blocking OSRF's entire Groovy sync, I'm hesitating to make new release into G, at least for now.

@k-okada
Copy link
Member

k-okada commented Apr 15, 2014

It does not needed but It always better to release them, but I understand your situation so I'll working on releasing into groovy until it becomes stable.

@k-okada k-okada reopened this Apr 15, 2014
@k-okada k-okada closed this as completed Apr 15, 2014
@130s
Copy link
Author

130s commented Apr 15, 2014

Let me be clear; I'm afraid adding new release might increase the risk of breaking the build. So I prefer to prioritizing making the buildfarm stable for Groovy.

@k-okada
Copy link
Member

k-okada commented Apr 15, 2014

As I wrote on start-jsk/rtmros_common#410 (comment), I suppose current situation is not because of groovy, but rmtros_comon itself is not enough stable. so even if we stop releasing on Groovy, it will break if we release on Hydro/Indigo and same bug fix will works for both releases.

By the way, how do we cope with start-jsk/hrpsys#75, they want to start using trunk version of hrpsys.

One idea is to create groovy branch on rtmros_common and stop developing/releasing and using hrpsys 315.1.x and hydro branch is continue developing on trunk (315.2.x), but this means hironx users must use groovy, so it may not acceptable.

Another idea is to create stable(315.1.x) branch on rtmros_common and only stable branch is released and deb build. This means main/core users never uses deb package. Also I afraid I mostly working on developing release so it just make you much more busy.

Another approach is to release rtmros_common and rtmros_comon_devel ?

Ideal approach is to update QNX software to 315.2.x but it may most difficult among above idea.

@130s
Copy link
Author

130s commented Apr 15, 2014

Let us continue at start-jsk/hrpsys#76

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

No branches or pull requests

2 participants