ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Proposal: Release schedule (Task #47)
I liked the 6 month major, 1 month minor release schedule I was doing with Redmine. I had a lot of feedback that it was nice to get bug fixes fast (minor) and to be able to schedule upgrades around the major releases.
I would like to tweak it a little bit though, since June/December releases are in the middle of major holidays.
I propose a release schedule of end of February and August. That will let us take advantage of the end of the summer (Google summer of code perhaps?).
I like the idea of "fixed" release dates. That forces the developers not to move too far away from the master branch as they want to see their feature(s) released.
You probably already discussed this, but can't we take this approach one step further with implementing a transparent project management process such as Scrum? It would be cool if everybody could see that a feature or fix is late for the next release and that the person can accelerate the development on that issue by participating himself. I believe that seeing your work helps achieving shared goals is extremely satisfying and fun.
A problem of open project planning is that people continuously criticize you for your plan... This will be our daily business :-)
Yea, I'm thinking it would be a loose "releases around these dates" with clear communication if things change. For example if we have to do a security release.
Whenever I've seen Scrum or XP applied to Open Source the results were very poor. I think it's because of the volunteer aspect, you can't base decisions on people who may or may not be able to work. If you have any ideas about how to adapt it, I'd be happy to try something.
I've read through SemVer and created a few wiki pages for what I propose for our release schedule. It's similar to what we were doing in Redmine except we are using the version numbers a bit differently: instead of using the Y part of the release for major releases, I propose we use the X part. This lets us match SemVer exactly. (reference: Version X.Y.Z). The only downside is that we will have version numbers increment fast but I don't think that's a problem since this software is over 4 years old already.
What do you think?
- Status deleted ()
I love the semantic versioning nomenclature, only thing I noticed is in the Release Standards, I don't see any mention of tests, which I feel should be "all pass" for a release, though I don't know if it should be applied to minor releases, or major ones only.
In my opinion, all tests should pass with every commit or the commit should be reverted. Once one test starts failing without it getting fixed, then the entire purpose of testing is lost.
I have some stuff covered in Code Review (still a rough draft), do you think it needs to be covered in the releases too?