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)

Added by Eric Davis at 2011-01-12 02:22 pm. Updated at 2011-01-27 11:21 pm.

Status:Closed Start date:2011-01-12
Priority:Normal Due date:
Assignee:Eric Davis % Done:

0%
Category:ChiliProject - Organization
Target version:Public Launch
Remote issue URL:

Description

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?).

Associated revisions

Revision 6fa5eb89
Added by Felix Schäfer at 2011-05-05 09:00 pm

Merge pull request #47 from schmidt/b/374-url-escaping-in-js-calls

Don't HTML-escaped URLs before passing them to the JavaScript helper. #374

History

#1
Updated by Eric Davis at 2011-01-12 03:11 pm

  • Target version set to Public Launch

#2
Updated by Felix Schäfer at 2011-01-13 01:06 am

If we don't make it too rigid a schedule (i.e. skipping a minor because there was more work on features/the next major rather than on fixes), I'm OK with that.

#3
Updated by Wieland Lindenthal at 2011-01-13 02:12 am

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 :-)

#4
Updated by Eric Davis at 2011-01-13 03:11 pm

Felix:

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.

Wieland:

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.

#5
Updated by Eric Davis at 2011-01-18 10:10 am

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.

Wiki pages: Release Schedule Release Standards

What do you think?

  • Status deleted ()

#6
Updated by Muntek Singh at 2011-01-20 02:51 am

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.

#7
Updated by Eric Davis at 2011-01-20 03:40 am

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?

#8
Updated by Eric Davis at 2011-01-22 12:50 am

Any more feedback on the Release Schedule proposal? Specifically 2.0.0 this year and 3.0.0 six months later?

  • Assignee set to Eric Davis

#9
Updated by Felix Schäfer at 2011-01-22 03:58 pm

Mmh, hadn't seen the proposal was a major release every 6 months, I fear that would be too hard a pace, but in honesty: I don't care much, it's "only" names/tags…

#10
Updated by Eric Davis at 2011-01-22 10:28 pm

I think if we don't try to stuff too many features into each major release it will be fine (i.e. look at it as "what can get done in 6 months" and not "MAJOR RELEASE, put in as many new features as possible!").

#11
Updated by Felix Schäfer at 2011-01-23 12:16 am

Yes, but most people tend to think of major releases as "ZOMG look at it, it should even have a kitchen sink now!!11" and look for a dozen new big awesome features ;-) Anyway, as I said, good for me, carry on :-P

#12
Updated by Eric Davis at 2011-01-27 11:21 pm

Felix:

At the same time, if there are a lot of changes then people tend to avoid upgrading out of fear of something breaking. Can't win either way :|

Since there aren't any other opinions, I'm going to mark this as closed.

  • Status set to Closed

Also available in: Atom PDF