| I get it. Sorry for being dense. I've been so heavily into component (aka modules, ...) lately that Bugzilla completely slipped my mind.
So yeah, this is unfortunate. I can see how the various bits of Gemini would want milestone independence etc. The only alternative I can see is reusing milestones. That is 1.1M3, the label, can be used by different components at different times. In any event, we don;t want to put you through any unnatural acts...
Jeff
On 2010-07-09, at 11:19 AM, Mike Keith wrote:
Subproject have their own milestones and release schedules, but having
different subproject milestones and releases does not preclude us from
doing exactly what you suggest, i.e. rolling up a group of subproject
releases into a single package of stuff and releasing it as a single
toplevel Gemini release. In fact I agree with the value that adds to
the community and think that we likely will do that, but the subproject
milestones will not be targeted at that level.
On 7/9/2010 10:31 AM, Thomas Watson wrote:
Sigh, yes this is true. Just so we all understand what it is that
you want to do I will try to reiterate.
1) Gemini has many (I'll call them) sub components.
2) The Gemini team/community has the goal to have each sub component
release independently on completely different schedules.
3) To put it another way, Gemini will not have a single release that
"roles" up all of its components and have them use the same release
schedule.
If that is the case then it really does look like you will need to go
back to separate products for each sub component. But I wonder about
this strategy. Each individual release will need its own IP Log,
release review, test pass, integration tests with other Gemini sub
projects etc. Maybe that is not a big deal and Gemini sees the benefits
outweigh the overhead. But I see benefits in having a single Gemini
release also.
1) Perhaps less confusion to the community. In Equinox we implement
many different bundles but we rally around a single Equinox release.
The bundles within the Gemini release can have individual versions, but
you role up all the versions into a consistent release schedule which
has a number of benefits.
2) The OSGi specification roles up many specifications into a release.
It seems like it would be relatively logical to set your Gemini
schedule up to align with the OSGi specification schedule. That is what
we try to do in Equinox.
I am not suggesting that the Equinox way is the only way or even the
best way. If you really want individual releases that happen at
different times then I am not going to object. But I want to make sure
that is really what is best for your community as well.
Tom
<Mail Attachment.gif>Mike Keith
---07/09/2010 08:33:31 AM---Sorry, I wasn't using a proper term, I was
just referring to the fact
<Mail Attachment.gif>
From: |
<Mail Attachment.gif>
Mike Keith <michael.keith@xxxxxxxxxx> |
<Mail Attachment.gif>
To: |
<Mail Attachment.gif>
Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> |
<Mail Attachment.gif>
Cc: |
<Mail Attachment.gif>
Runtime Project PMC mailing list
<rt-pmc@xxxxxxxxxxx> |
<Mail Attachment.gif>
Date: |
<Mail Attachment.gif>
07/09/2010 08:33 AM |
<Mail Attachment.gif>
Subject: |
<Mail Attachment.gif>
Re: [rt-pmc] Gemini subprojects/components |
Sorry, I wasn't using a proper term, I was just referring to the
fact
that the "Target Milestone" in a bug appears to be product milestones,
not component milestones, and that according to the webmaster there is
no way to have different milestone sets for different components of the
same product.
On 7/8/2010 7:13 PM, Jeff McAffer wrote:
> Hey Mike,
>
> Can you clarify what version pool you are talking about? I've
never heard of such a thing and we've been numbering our bundles etc
independently for years.
>
> Jeff
>
>
> On 2010-07-08, at 2:37 PM, Mike Keith wrote:
>
>
>> A little while ago it was suggested that we merge the various
subprojects of Gemini into components of a single Gemini product, and
this was recently done by the webmaster. Unfortunately, what we are now
finding is that there is no component versioning, and that all of the
components must reference the same version number pool. This totally
breaks what Gemini is, allowing different subprojects to release at
different times and with different version numbers, so unless there is
an alternate solution that somebody wants to suggest, we will be forced
to go back to having a separate product for each subproject.
>>
>> -Mike
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
|
