> thanks for the quick response again.
> Some of the components aren't as ready as others, and I personally
> wouldn't have added them to the download list yet. I see what
> mean about binary download availability though, and we definitely
> need to fix that.
Sounds right .... you may just need a way to indicate
which are planned for Luna,
and which are not.
> We haven't been keeping up older builds because generally the newest
> is definitely the best. Some of the older Hudson builds are
> the Hudson workspace. Currently the output from the C build
is put here:
but again, it's only the
> latest one. We could change that to keep history.
One reason to "keep history", is that, as you
mature, you may find you have
adopters that are using/testing an "old" version
(say, with their own
internal client ... or "value add client") and
they may well be planning to "move up" to the new version
at some point, but they might not be ready yet, and may
still need the older
version for a few weeks/months ... eventually years! :\
That's what we mean by asking projects to have a "retention
adopters know what to expect.
I'm not sure. Definitely something simple and easy for
you. And something "near" the downloadable binary or artifacts.
And fine if they temporarily "point back" to
Hudson ... but eventually you'll want them on "downloads".
("downloads" is actually "backed up",
made for heavy use, etc., whereas Hudson, even if you mark something as
"keep this build" is not backed up and those "keep forever"
builds will disappear some day -- such as after a disk crash, Hudson upgrade,
or something :)
Perhaps a short summary, that "linked" to the
more detailed, specific results ... such as