On 3/28/07, Karl Fogel <kfogel@red-bean.com> wrote:
>
> "Erik Huelsmann" <ehuels@gmail.com> writes:
> > I see a big difference in philosophy here and I do think it's not
> > something to shrug about really, because as long as we don't actually
> > choose for one or the other, I'm feeling we're going to have last
> > weeks discussion on every release.
>
> Sorry, I didn't mean to imply that I was shrugging off the issue.
>
> One thing that might help would be for us to stop insisting that every
> minor release number must mean at least one major new feature.
> Instead, it could just be that we feel the code has progressed far
> enough, and enough bugs have been fixed (but not backported), that
> it's time for something bigger than a patch release.
>
> I think this would cut down on a lot of frustration, because people
> who have made improvements (including minor new features that wouldn't
> by themselves justify a release under the current system) would see
> them get out the door sooner. At the same time, if a major feature is
> close to being done, we can try to coordinate it with the release --
> no need to be dogmatic either way about it.
>
> Thoughts?
No one has replied to my suggestion, and I think it strikes a compromise.
We still have a roadmap, we try to stick to the roadmap, but we take
timeline into consideration when planning the roadmap. Whether that is one
release every 6-8 months or 10-12 months is just a detail. I think that an
approach like this can satisfy both camps and also lead to less conflict.
If there is no basic roadmap then it seems inevitable that there are going
to be disagreements about whether we have enough to do a release. If we have
a roadmap that defines the goals for the release, then we can always say,
feature X is taking longer than we thought, lets push that to the next
release and do a release now.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Wed Mar 28 22:07:15 2007