Re: [virgo-dev] [rt-pmc] Virgo release branding

[Glyn Normington <gnormington@xxxxxxxxxx>]

Hi Wayne

It would be good to finalise this discussion soon, at least for the urgent example of Virgo 3.0.

In Virgo 3.0 we want to release v2.4.0 of the GreenPages sample at the same time, in this instance covered by the same release docuware and frozen IP log, but at a distinct version and not part of a subproject.

Is this particular case acceptable?

If so, we can defer the discussion of other examples until they come up (unless you would like to sort out the whole topic soon, while it is still "warm").

Regards,
Glyn

On 14 Jul 2011, at 10:43, Glyn Normington wrote:

> Hi Wayne
> 
> Comments inline...
> 
> Regards,
> Glyn
> 
> On 13 Jul 2011, at 19:56, Wayne Beaton wrote:
> 
>> I'm pretty sure that the EDP supports the notion. At least it provides
>> enough wiggle room that it could be interpreted in that way.
> 
> Excellent!
> 
>> 
>> My primary concern is confusion in the community. My feeling is that the
>> Virgo project is doing a bunch of potentially confusing things. Okay...
>> At least two. Non-sequential version names in lieu of numbers will be
>> confusing.
> 
> We are actually sticking with normal version numbers. The branding is simply a convenient way to refer to related deliverables. For instance, if the schedule permitted, we could brand Virgo 3.5 and Virgo IDE 1.0 as "Azure".
> 
>> I assume that the separation within the project will use
>> similar non-sequential, likely-unrelated names?
> 
> No. Each deliverable will have its own sequential version numbering.
> 
>> 
>> Do you have a plan for keeping the different things that you're
>> releasing coordinated?
> 
> Yes. For example, each time we release a sample, the sample describes which versions of the runtime and tooling it was developed with.
> 
> More interestingly, a given version of the Virgo IDE tooling will support a range of versions of the Virgo runtime. In general, we don't want to force people to upgrade the tooling when they choose to upgrade the runtime or vice versa. The model is really that you get on a suitable version of the runtime and the tooling and then step up to the next version of either when it suits you. Of course, there will be exceptions if we make incompatible changes at a major version boundary, but that shouldn't be the norm.
> 
>> 
>> My understanding is that bundlor is something that's useful outside of
>> Virgo. By keeping it in Virgo, you are excluding a large part of the
>> community that (a) won't think to look for it there, or (b) will assume
>> that it is Virgo-specific. Is it time to move that piece to Tools?
> 
> I'm open to this, but I think it is a somewhat separate topic to the current discussion. I'd like the freedom to release bundlor out of Virgo before very long and it would probably take a while longer to transfer bundlor to Tools, assuming we can resource that activity.
> 
>> 
>> Is the "IDE Tooling" Virgo-specific?
> 
> Yes. Our intention in the fulness of time (i.e. after the first release) is to move non-Virgo-specific function into Libra and then make the Virgo IDE tooling extend Libra to add back in the Virgo specifics.
> 
>> 
>> Are the PMC meeting minutes available for review?
> 
> Tom kindly sent a link.
> 
>> 
>> Wayne
>> 
>> On 07/13/2011 10:03 AM, Glyn Normington wrote:
>>> Hi Wayne
>>> 
>>> We discussed this topic at today's RT PMC call and there was a general consensus that the ability to release parts of a project without the overhead of putting those parts in subprojects would be very useful. Of course, the usual release review and IP log freezing process would be required.
>>> 
>>> So what else do we need to consider before we can agree this approach?
>>> 
>>> Thanks,
>>> Glyn
>>> 
>>> On 17 Jun 2011, at 17:09, Wayne Beaton wrote:
>>> 
>>>> On 06/17/2011 11:58 AM, Glyn Normington wrote:
>>>>> 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... ;-)
>>>>> 
>>>> Like I said, we're set up for projects having a single release stream,
>>>> so you may have to be patient with me and help me figure this out. I'd
>>>> rather avoid make-work as well. I'd only recommend making a separate
>>>> project if it makes sense for your committer base and community. At this
>>>> point, I don't believe that this is the case. This may change with time.
>>>> 
>>>> Had the PMC weighed in on this? They may have an opinion about the split
>>>> between runtimes and tools.
>>>> 
>>>> Wayne
>>>> _______________________________________________
>>>> virgo-dev mailing list
>>>> virgo-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>> _______________________________________________
>>> rt-pmc mailing list
>>> rt-pmc@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>> 
>> -- 
>> Wayne Beaton
>> The Eclipse Foundation
>> Twitter: @waynebeaton
>> 
>> _______________________________________________
>> virgo-dev mailing list
>> virgo-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>