Hi, in preparation for this evening's developer conference call (email me or Marek if you want to participate / listen in), I want to propose part of our agenda for discussion, by following up on Marek and Titus' discussion of the need for a release. I'll summarize their comments in brief caricatures:
- Marek: "release early and release often" is essential for an open source project. We are endlessly delaying the release with continuous feature-creep. - Titus: the software alone is not enough; we have a lot of work to do on the tutorials before we can invite the world to dive into Pygr by making a big, public release. A few observations that may help bridge these different positions: - by keeping ourselves locked up in the 0.8 feature-creep dynamic, we are restricting our attention and audience mostly to our little developer group (i.e. only people who get Pygr using git) instead of real users. This loss of focus on real users in the long-run is very unhealthy. Only packaged releases can get us out of this dynamic. That is the logic of "release early and release often" that Marek is highlighting, and I think he's right. - this dynamic is also holding us back from moving on to the useful new feature area that users want, i.e. deep sequencing data. That seems like a serious mistake to me. - I think the right resolution of Titus' concerns is to de-couple the 0.8 release from the "major publicity push" that was Titus' real concern. Frankly, I don't think the 0.8 release will automatically lead to zillions of people immediately leaping into Pygr; instead I think it will lead to slow, incremental growth more or less like what we have already seen. - Stated another way: is an 0.8 release a bad idea because the tutorials lack sufficient depth, given that the previous stable version (0.7) suffers the same limitation? No -- 0.8 is a big improvement over 0.7, so finalizing this release is incremental progress that yields only advantages, with no serious disadvantages (vs. 0.7) that I'm aware of. - Looking back at Pygr's history: I deliberately numbered the first release as 0.1 to emphasize that this was an exploratory project that would continue to refactor. In the 5-6 years since then we've stepped through the decimals one by one, even though in traditional software terms putting a year's worth of work into a raft of new features (e.g. pygr.Data) would normally be treated as a +1 step rather than the +0.1 step that we labelled it. We tried to follow the open source spirit of "Underpromise, overdeliver". Perhaps we've taken that to an extreme. Most people would find it surprising that we're arguing over blocking a one-year-delayed *point* release (i.e. +0.1) with arguments not about the software, or even the completeness of the reference docs, but about whether the extra tutorials are deep enough to foster broad popularity. - It sounds to me like we're arguing not about an 0.8 release, but about whether we're ready for a very public, 1.0 release. "Foster broad popularity" was never in the 0.8 spec, so this must honestly be called feature-creep. I think those arguments should be applied when they will be appropriate, i.e. a big, public 1.0 release. I therefore propose that we switch to a "micro" point release process more like what Pyrex follows (e.g. their recent releases are: 0.9.8.2, 0.9.8.3, 0.9.8.4, 0.9.8.5). - We release 0.8 beta with the latest changes. - We then fix a bunch of bugs with as much user feedback as people will give us over a SET period of time (e.g. one month? two months? I am skeptical that we are getting a high enough volume of feedback to justify a longer period for bug fixing). - We release the fixed version as 0.8.0, with the expectation that we will probably be making further point releases 0.8.1, 0.8.2 ... as growing usage raises new how-to questions and presumably bugs. - We proceed to work on the tutorials via direct collaboration with users: if someone asks a question that seems highly relevant, we work directly with them to show a good way for solving their problem with Pygr. We capture each of those as a new tutorial. If there are code changes / bug fixes associated with that process, we make point releases frequently (so that we do NOT tell users to "access the latest Pygr source using git"). - meanwhile some of us will be starting work on 0.9 features... If these are incremental additions, they can also be released in a point- release style. If they involve major new components, refactoring or code review, they stay in the unreleased 0.9 branch (only accessible via git until we start making 0.9 alpha releases). -- Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
