[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [virgo-dev] Virgo release branding
|
Hi Wayne
On 17 Jun 2011, at 16:27, Wayne Beaton wrote:
> Sorry that I'm coming late to this party...
>
> FWIW, I totally love the idea of naming your releases. My preference would be go with something fun/funny (comedian names, Dr. Seuss words?); but fun/funny is actually a pretty hard problem.
Thanks for the suggestion.
>
> Talk of projects releasing different parts of their code on different schedules raises a bit of a red flag with me. I assume that issues regarding version mismatches between runtime and tools have been considered. Is there concern that differences between runtime and tools version numbers may cause confusion in the community?
Understood. However, we have current use cases where one version of the tooling supports several versions of Virgo and one version of Virgo will run with several versions of the tooling so that people don't have to upgrade both together. That's why we need the freedom to version and release the tooling and runtime independently. We'll probably ship an ideally matched pair of Virgo 3.5 and Virgo IDE 1.0 pretty close to simultaneously in due course, but that's the exception rather than the rule.
>
> Our processes really only have a concept of a project and a release. There really is no concept of parts of a project doing a release. This isn't a show stopper; it just means that we may need to be creative with the process to make sure that the intent is clear. We may need to work together to make sure we get this right. Keep in mind that anything you call a "release" (other than service releases) requires a release review...
Yes, of course.
>
> Again, I assume that these sorts of issues are being considered, I just haven't been paying close enough attention to this conversation.
I am wondering whether we'll need to put the IDE tooling, the bundlor manifest generation tool, and each of the samples in their own subprojects to give us the necessary versioning and release flexibility. It *feels* mostly like make-work, but I guess it would be easier to keep the IP logs straight that way. If, OTOH, there is a slicker solution, I'm all ears as I have better things to do than re-arrange project metadata... ;-)
Regards,
Glyn
