[messages] [Developers] Roadmap for VASSAL 4
ainulindale at gmail.com
Mon Sep 3 00:14:06 MST 2012
Yesterday we had an interesting talk with Uckelman (to which Tim added his
opinion later on but everyone was sleeping), and I thought that it'd be
worth talking here.
As to release planning and features delivery for V4, what would you prefer?
1) "Rolling-release" like, that is implementing feature by feature then
releasing that feature into main V4 when deemed stable enough
2) Monolithic release, that is implementing all features and releasing when
they're all in
Obviously, this depends a lot on what is behind a "feature". Yesterday,
discussion was about hex grid generators and coordinate systems. We could
have a "start top left" system of coordinates for an hex grid such as A1,
A2... B1, B2, ... We could also have a "snail type" coordinate system in
which hexes are originated in the center of the grid. I'm sure we could
find games with weird system of coordinates. Here is an example of
For those of you who don't want to see my opinion before you think about
yours, this is the safe point to stop reading :-)
My point was in this discussion that we'll always find different ways to
implement this or that feature with this or that specificity.
Hence, in my opinion, we should draft the most basic one which will cover
90% of cases, allow from flexibility from the start (scripting?), do a
first release that way, and then when all basic functionnalities will cover
90% of all possible modules, add the missing parts.
As ever, the common 90% take 10% of the time, and the specific 10% take 90%
This doesn't prevent us from thinking about what should be done to cover
all possibilities. But, in my opinion again, this allows us to release more
regularly, keep people interested in what we do (especially potential
developers), as well as allow designers who only need this or that
functionnality to implement their module. It seems to me that this is a
really good way to show people that the project is going forward, which
isn't quite seeable if one has to browse through git to see changes. Plus,
past experiences have shown me that in open source projects, if you don't
focus on a specific part as a group with a short term objective in mind,
it's really hard to get anything done in a reasonable amount of time.
That's why I'm obviously a solution 1 guy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the messages