Let me throw something in the discussion so other people say what they think also. After all, this is a collaborative project, and now's the time to hear what people want to do.

I agree with Daniel that we should try to be cleaner and not commit things that break the whole compile process. But simultaneously, I think it's more interesting for us all to have a stable release for the following reasons:
- it has more impact, looks more serious, and does not run the risk of not working.
- it is cool for us: There are 29 modules in the $IMP/src/modules folder. Does anyone know what all of these models do? Does anyone even know what *any* of these modules do (except for their own modules, and maybe core and atom)? I don't! I'm sure rmf and parallel are super useful for me but never dared opening the folder.
I believe like Ben that a new release is a good thing because it forces us to advertise what we've been doing so far, and by advertising I just mean telling our labmates and maybe give them hints and new ideas on how to do things.
Now as Daniel pointed out, we don't have much time to spend on that, so I'm suggesting the following. Why don't we set a date in a more or less short term, and decide that by then, every module should be working without bugs, and have a decent documentation and some examples. A release for which it's *not* the right time to code new neat features, but that's just like a snapshot of what can be done at the moment. I mean the shortest path to what looks reasonably like a new release, not perfect but working great. We could even do this on a per-module basis, saying that for the ISD module (for example), revision number 124567 is the good one that should be used for the new release. Once everyone has it's revision number ready, Daniel or Ben (just a suggestion) try to fix the last bugs where modules don't work together, and then we're good.
If we did so, I believe this would represent less than a week's work, mainly to write a documentation, so having a release in a few months should be no big deal. We could even celebrate that by having a beer party and some talks of each module writers so they run us through the examples of their modules to understand how they work.

what do you think?

Y

Le 15/12/11 05:35, Daniel Russel a écrit :
In my understanding the things provided by periodic software releases are:
1) a chance to fix outstanding bugs
2) a way of solving packaging and distribution problems
3) a way to avoid having people use code during major changes
4) an opportunity to apply more manual testing
5) a target time for implementation of new features

As a result of various properties of IMP discussed below, I'm not seeing that we would much benefit from them compared to providing given slightly better access to nightly builds. As a result, it seems to me that effort would be better spent on keeping the day to day state of things better (writing more nightly tests, providing infrastructure for weekly tests of more involved things, better automation of things etc).


The above problems addressed by released don't really apply to IMP since
1) we don't tend to have outstanding bugs sitting around as most bugs encountered are blocking for projects and so fixed in relatively short order
2) these days, packaging for downloadable software is pretty automatic
3) given the way IMP is structured as various loosely coupled classes and modules, significant changes can be implemented as a parallel module or class and then swapped for the old one when ready, so we don't really have period where previously working code is broken for a long time
4) we are add automatic tests as we think of things and through using IMP constantly are doing more manual testing of it every day than we would do for a release
5) people's schedules tend to be dictated by their other projects. Features are implemented as needed for research/publications and it is hard to get anyone to devote significant time to an external imposed deadline.


The IMP 1.0 release was very much delayed, and by about a month out was something that someone should probably think hard about using instead of a carefully chosen svn build (based on bugs I found and fixed after the release and which were never backported). We have then had an extremely long time pass since and pushed back the next release by months while waiting for a couple of weeks work. We can say that we will, in the future, devote more resources to release-related functionality, but people will always want to spend their time on other things and I think they are, in general, justified given the role that IMP plays.

As an alternative, we could have been providing transparent access to builds (so you can easily figure out if the build yesterday passed all the tests you care about and check it out or download it with a copy and paste or a click), then we make the cost of having people upgrade when bug fixes or new features are added.


_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev