Hi Dan,
quote: Perhaps I got the wrong end of the stick but it seems like you had a pretty open beta for v2 for almost a couple of years and for a lot of that time it was close to production-ready.
Yup, that's a good description of how it went. I think there was only really 1 beta release for v2 that was seriously messed up and I put out a new one just a couple of days after it to fix it up.
Other than that one release they were all highly stable.
I just generally put a high priority on stabilizing things and fixing bugs more as I go along instead of postponing them all until the end. I think keeping the quality high all the time like this actually ends up saving a lot of time in the long run.
quote:
Will it be something like:
-V2 docs completed, v2 ships
-Holiday!
-Planning for next version
-Six months later, v3 rolling beta starts
-New functions added bit by bit over 6-12 months
-New functions frozen
-Final bug fixes, tidy up docs and ship v3
Or will it be more conventional sort of approach i.e. we wait 18 months and suddenly one day a fairly complete v3 appears with a frozen feature set and the package is shipped after 3 months of beta testing?
Well, the idea is to do something more like the first type which is kind of like how v2 went.
It just produces a much higher quality end result to do it like that, not only just for stability but also being able to incorporate feedback and suggestions.
When possible I do like to finish up individual features more completely earlier in the cycle, instead of there really being a single "New functions frozen" stage like you're listing above.
- Michael |
