Nicola Ken Barozzi wrote:
Tim Williams wrote:
....
Imagine that all cutting-edge users can use the trunk in production. A
patch is just a couple of actions away. And after incorporation, the
check is instantaneous, and on a *real* test, as it actually get used.
I may be very well be in a unique situation but I can't imagine many
folks are able to run a trunk on a live production machine? What
about the CM baggage? If I were a client of that *real* test, I think
I'd be concerned. If the recent JRE-version related discussion around
release time are any indiciation, this is not necessarily unique.
I have a small company with about 15 people that use the Intranet
site. Being also a developer, I have no problem in using the latest
code in "production". It's a small percentage of all usages, but still
relevant for us.
This can only work if the trunk is always *usable*, and not only
_buildable_. This can make our trunk be really bug-free, as there would
really be a lot of eyes looking at the code.
I said before that I do like a usable trunk (i.e. buildable + runnable
with no hoop jumping).
I would thus propose that the trunk be always *releaseable* at all
times, and that all new functionality that interferes with usage of
prior features be developed on separate branches.
This, however, is quite a committment. While I'm for a usable trunk,
extending that though to a "releasable trunk" is more committment than
I'd want. Maybe I'm reading too much into it but claiming that at any
given moment the trunk is [apache] release quality is bold.
Ok, probably the wording is too strong.
Furthremore, these branches should merge whenever possible between them
in a single branch so that they can be coded together, and get merged
with the trunk only when all developer-known bugs are fixed.
I understand that there will inevitably be dependencies between
branches but I don't care for merging branches into a single branch
(btw, wouldn't that ultimately become the defacto dev trunk?).
There should not be dependencies between branches. If there is, then
it should merge in a single branch.
This will also make it easier for us to release often, and to learn to
make smaller reversible changes rather than big ones that are hard to
understand by other developers and users.
Let me know what you think.
I guess the summary is that this sounds like an "Always-Branch" system
as opposed to the more pragmatic "Branch-When-Needed system" and that
seems overly rigid for little return. In other words, I doubt that a
lot of folks are able to run a trunk in a production environment and
so burdening yourselves with the overhead of maintaining a trunk in a
"releasable state" for what would amount to a handful of folks that
could use it (and likely already have svn loaded anyway) doesn't seem
worth it.
I am one of those, and I think that most Forrest developers are. If we
have at least a couple of others willing to use it, we're set.
I have omitted another thing though, that I would like to release
Forrest *with* SVN stuff, so that patches can always be easy to make
and to send.
As for the difficulty of maintaining a "releaseable" trunk, see my
next reply. Thanks for your mail, it helps :-)
I just wanted to pipe in here real quickly to add another data point to
the discussion. I am not a real dev, just a tweaker and poker, so most
of this discussion is not really for me to get involved in but I do want
to work with forrest and help as much as possible. I do like the idea
of a using trunk for production. I am serving about 150 people on our
intranet and wouldn't mind using it for our stuff. We haven't
implemented Forrest yet, but I plan to by October. I already have our
test system set up to run off trunk while I've been playing, so if trunk
were always in a usable state, I don't have to change anything.
Addi
