Task #3252
closedRelease 0.4.0-beta2
100%
Description
Release ndn-cxx, NFD version 0.4.0-beta2.
- write release notes, and update
RELEASE_NOTES.rst
anddocs/RELEASE_NOTES.rst
pointers - increment version number in
wscript
- publish source and binary packages
- send announcement
Updated by Davide Pesavento about 9 years ago
is a beta2/rc2 worth it, given that 0.4.0 final is expected before the end of the month?
Updated by Junxiao Shi about 9 years ago
beta2 is necessary to deploy #3236 on testbed.
Updated by Davide Pesavento about 9 years ago
That still doesn't justify a beta2 IMHO. The testbed runs 0.3.4, therefore we should create a 0.3.5 from it that includes just that additional fix.
Updated by Alex Afanasyev about 9 years ago
We need to fix the memory leak issue on the testbed asap. We can do it without making a formal beta release, though this will effectively be beta anyways.
Updated by Davide Pesavento about 9 years ago
You're missing my point. If you just want to fix that particular bug, the best way is to branch from 0.3.4, backport the commit (e.g. cherry-pick), and tag 0.3.5 on that branch. This way you don't risk introducing (unknown) regressions caused by other commits that landed on master after 0.3.4 (there have been several major changes so the risk is quite high).
Alternatively, you can just release updated binary packages of 0.3.4 + the memleak patch (.deb packages have a specific version component exactly for this kind of things).
Updated by Alex Afanasyev about 9 years ago
We had exactly this discussion during yesterday's NFD call. You're right that we don't need to have release to make a package with a fix; we can fix just 0.3.4 release and apply on the testbed. However, we want to test out the new code as early as possible and making a second beta (or just a binary package from current master) addresses this desire.
Updated by Junxiao Shi about 9 years ago
- Due date set to 10/24/2015
Alex confirms during 20151020 conference call that the release will happen this week.
Updated by Alex Afanasyev about 9 years ago
- Status changed from New to Code review
- % Done changed from 0 to 50
Updated by Junxiao Shi about 9 years ago
- Status changed from Code review to Resolved
Code is merged. This task still needs packages and announcement.
Updated by Davide Pesavento about 9 years ago
Guys, the tagging in git(hub) is completely messed up at the moment. I'm just pointing this out so that it doesn't happen again.
The current situation is that it looks like rc1 is the latest tagged release, while in fact it's older than beta2... If beta1/rc1 was wrongly tagged as rc1 (instead of beta1) at the time, we should just have accepted it, and continued with -rc2, -rc3, and so on for the later releases. Going back to -betaX was not a good idea.
Fortunately, at least the date of a tag can be fixed retroactively: http://stackoverflow.com/questions/21738647/change-date-of-git-tag-or-github-release-based-on-it This should ensure that at least github displays the releases in the proper chronological order.
Updated by Junxiao Shi about 9 years ago
I disagree with note-10. We should delete rc1
tag, and create a beta1
tag for the previous release, and use beta2
tag for this release.
Updated by Davide Pesavento about 9 years ago
You disagree with what in note-10 exactly? You do agree that there is a problem with tagging, right?
Anyway, the problem with deleting tags is that you can't really delete them from other people's repos... if someone already pulled the tag (like I did), they will have it forever in their clone.
Updated by Junxiao Shi about 9 years ago
- Status changed from Resolved to Closed
- % Done changed from 50 to 100