Given comments so far, it seems to me like a good idea to try. And now seems as good a time as any. So shall we have our first mini-release by next week? In practice, that would mean that we branch in git. I would then encourage people who only update IMP occasionally to update to that branch. Patches would be moved to the release branch on a more or less as-needed basis, or if it is something that is a simple bug to fix.
Sounds worth a try?
See https://github.com/salilab/imp/issues/256 for more context.
On Apr 10, 2013, at 7:15 AM, Daniel Russel drussel@gmail.com wrote:
How about two stages? I. By April 20th - Anyone who wants to update and check in their code to the release, document further, etc - do so by end of next week. II. By April 30th - branching out of Apr 20th code, extensive testing, minor updates and mini release
On Apr 10, 2013, at 6:27 PM, Daniel Russel drussel@gmail.com wrote:
> Given comments so far, it seems to me like a good idea to try. And now seems as good a time as any. So shall we have our first mini-release by next week? In practice, that would mean that we branch in git. I would then encourage people who only update IMP occasionally to update to that branch. Patches would be moved to the release branch on a more or less as-needed basis, or if it is something that is a simple bug to fix. > > Sounds worth a try? > > See https://github.com/salilab/imp/issues/256 for more context. > > > On Apr 10, 2013, at 7:15 AM, Daniel Russel drussel@gmail.com wrote: > >> https://github.com/salilab/imp/issues/256 > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Does anyone have code they want to check in in the next week or so? I'd suggest that anyone who has changes they want to make, add an issue in the issue tracker and make the mini-release milestone depend on it (so we can keep track).
For extra testing, I suggest that over the next week, people try to run their code against a current IMP and make sure it all works. I think for this process to work going forwards it has to be fairly light weight and not involve significant amounts of extra testing.
Does that make sense?
On Apr 10, 2013, at 6:46 PM, Barak.raveh barak.raveh@gmail.com wrote:
> How about two stages? > I. By April 20th - Anyone who wants to update and check in their code to the release, document further, etc - do so by end of next week. > II. By April 30th - branching out of Apr 20th code, extensive testing, minor updates and mini release > > On Apr 10, 2013, at 6:27 PM, Daniel Russel drussel@gmail.com wrote: > >> Given comments so far, it seems to me like a good idea to try. And now seems as good a time as any. So shall we have our first mini-release by next week? In practice, that would mean that we branch in git. I would then encourage people who only update IMP occasionally to update to that branch. Patches would be moved to the release branch on a more or less as-needed basis, or if it is something that is a simple bug to fix. >> >> Sounds worth a try? >> >> See https://github.com/salilab/imp/issues/256 for more context. >> >> >> On Apr 10, 2013, at 7:15 AM, Daniel Russel drussel@gmail.com wrote: >> >>> https://github.com/salilab/imp/issues/256 >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Or to put it another way, I think the main improvement to aim for over the current system is that we have a stable branch where bugs can be and will be patched, but significant changes will not occur (as opposed to trying to create a particular stage that has significantly fewer bugs than normal, because we haven't had much luck with trying that as everyone always has too many other things to do).
> For extra testing, I suggest that over the next week, people try to run their code against a current IMP and make sure it all works. I think for this process to work going forwards it has to be fairly light weight and not involve significant amounts of extra testing. > > Does that make sense? > > On Apr 10, 2013, at 6:46 PM, Barak.raveh barak.raveh@gmail.com wrote: > >> How about two stages? >> I. By April 20th - Anyone who wants to update and check in their code to the release, document further, etc - do so by end of next week. >> II. By April 30th - branching out of Apr 20th code, extensive testing, minor updates and mini release >> >> On Apr 10, 2013, at 6:27 PM, Daniel Russel drussel@gmail.com wrote: >> >>> Given comments so far, it seems to me like a good idea to try. And now seems as good a time as any. So shall we have our first mini-release by next week? In practice, that would mean that we branch in git. I would then encourage people who only update IMP occasionally to update to that branch. Patches would be moved to the release branch on a more or less as-needed basis, or if it is something that is a simple bug to fix. >>> >>> Sounds worth a try? >>> >>> See https://github.com/salilab/imp/issues/256 for more context. >>> >>> >>> On Apr 10, 2013, at 7:15 AM, Daniel Russel drussel@gmail.com wrote: >>> >>>> https://github.com/salilab/imp/issues/256 >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >
On 4/10/13 6:27 PM, Daniel Russel wrote: > Given comments so far, it seems to me like a good idea to try. And > now seems as good a time as any. So shall we have our first > mini-release by next week?
Given your proposed timeframe (4-6 months between mini releases) and my proposed timeframe for "normal" releases (6 months) there seems little point in making a distinction - the "mini" releases should just be releases. As long as everything compiles, the examples actually work, and there aren't any serious test failures (this last is open to interpretation, of course!), we may as well make a full release. (Then we can also replace the outdated 1.0 release on the website.) The only blocker for a 2.0 release (to my knowledge) is MultiFit, and I should have that documented and working well enough by the end of next week. So Barak's suggestion seems reasonable to me.
Of course, there's no reason not to also have a stable branch updated at the same time as a numbered release.
Ben
On Apr 11, 2013, at 4:40 PM, Ben Webb ben@salilab.org wrote:
> On 4/10/13 6:27 PM, Daniel Russel wrote: >> Given comments so far, it seems to me like a good idea to try. And >> now seems as good a time as any. So shall we have our first >> mini-release by next week? > > Given your proposed timeframe (4-6 months between mini releases) and my proposed timeframe for "normal" releases (6 months) there seems little point in making a distinction - the "mini" releases should just be releases. Definitely doesn't make sense to have both.
> As long as everything compiles, the examples actually work, > and there aren't any serious test failures (this last is open to interpretation, of course!), we may as well make a full release. And the current state is more or less there :-)
> (Then we can also replace the outdated 1.0 release on the website.) The only blocker for a 2.0 release (to my knowledge) is MultiFit, and I should have that documented and working well enough by the end of next week. Yes. Part of the point of naming it mini-release is so multifit is no longer a blocker as it has dragged the release process back kind of ridiculously. And since anything that involves people putting significant work other than their projects doesn't tend to happen, so it should be as light weight as possible.
> Of course, there's no reason not to also have a stable branch updated at the same time as a numbered release. What would be the benefit of a third branch? I think having develop being develop and master being a 6 month release branch seems like a reasonable thing. And with git-flow it is pretty easy to manage patches that should go to both.
On 4/11/13 5:15 PM, Daniel Russel wrote: >> As long as everything compiles, the examples actually work, and >> there aren't any serious test failures (this last is open to >> interpretation, of course!), we may as well make a full release. > And the current state is more or less there :-)
Indeed. Great work everybody!
>> Of course, there's no reason not to also have a stable branch >> updated at the same time as a numbered release. > What would be the benefit of a third branch?
Not a branch in the same sense, but a tag (which in SVN at least are just branches that aren't updated). So we update master every 6 months as the release branch, and just tag it each time with a version number (2.0, 2.1, etc.). Then I'll build binary packages and update the website with that. Easier to remember a version number than a git hash. ;)
Ben
> >>> Of course, there's no reason not to also have a stable branch >>> updated at the same time as a numbered release. >> What would be the benefit of a third branch? > > Not a branch in the same sense, but a tag (which in SVN at least are just branches that aren't updated). So we update master every 6 months as the release branch, and just tag it each time with a version number (2.0, 2.1, etc.). Then I'll build binary packages and update the website with that. Easier to remember a version number than a git hash. ;) Names are definitely easier to remember than hashes :-) My concerns with tags are logistical ones which may well have nice solutions (and may be handle by git flow automatically even, but I haven't played with this part of it yet). (I think) we would like to actively patch the release branch when there are bugs. =If we want the branch tags to be uniquely meaningful (so there aren't multiple versions called git 2.0 floating around), then we have to make sure we update them each time we patch. This could be done via point releases, but I'm not sure we will want to go through the effort of that. The best may be to have the 2.0 tag and then something that updates the tag automatically whenever a patch is (eg by suffixing the git hash tag).
-
Barak.raveh -
Ben Webb -
Daniel Russel