i had a rather large change recently where it would have made my professional life much easier if i had committed it to 3.0 (vs. the trunk and 3.1). that was about a month ago, and 3.0 was at RC 1. now i (the professional "i") am up the creek if roller 3.1 doesn't release sometime in the near future.

but that's my problem, and i only brought it up because i *think* it's an example of the way things should work. a less aggressive approach to feature addition make sense. developers shouldn't worry about the release number. work on features, and whatever release they fall into depends on when they are complete. we shouldn't be targeting features for a particular release.

the problem is when features are worked on the trunk. then they are forcefully committed to the next release. which is why it makes sense to use the sandbox model for feature dev. in my professional life, we do the same thing, except that we actually create CVS branches for feature dev, and merge back into the trunk only when the feature is release ready (well, that's how it works in theory).

Elias Torres wrote:
I've been with Roller for sometime now but it is until recently that I
have been working closely with to the development lifecycle. At the end
of 3.0 we submitted proposals for working on 3.1 and those got approved
so we are making plans based on those proposals and dates estimates.
However, there have been a couple or more proposals that appear last
minute before code freeze and get submitted/implemented. I'm just trying
to figure out our process and what's good practice and what's not. I'm
not sure how would you feel if I submitted a few proposals this week on
behalf of IBM's needs as opposed to waiting for 3.2. I'm not saying that
we can't work like this, but I'm trying to understand what is acceptable
or not to this community. I definitely don't want to misbehave in the
friendly/cooperative environment we have today.

As I look into the future of IBM and Roller I'm not sure we'll have tons
of proposals closely tied to the schedule because we won't be able to
keep up with Roller's short lifecycle. Our direction is going to be more
like: get a feature implemented in whichever release it happens to fall
under and we backport it to our internal version until we make the jump
to let's say 4.0.

-Elias

Reply via email to