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.rstanddocs/RELEASE_NOTES.rstpointers - increment version number in 
wscript - publish source and binary packages
 - send announcement
 
      
      Updated by Davide Pesavento about 10 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 10 years ago
      
    
    beta2 is necessary to deploy #3236 on testbed.
      
      Updated by Davide Pesavento about 10 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 10 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 10 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 10 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 10 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 10 years ago
      
    
    - Status changed from New to Code review
 - % Done changed from 0 to 50
 
      
      Updated by Junxiao Shi about 10 years ago
      
    
    - Status changed from Code review to Resolved
 
Code is merged. This task still needs packages and announcement.
      
      Updated by Davide Pesavento about 10 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 10 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 10 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 10 years ago
      
    
    - Status changed from Resolved to Closed
 - % Done changed from 50 to 100