[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [orbit-dev] How to handle RC's?
|
Hi,
+1 for keeping the same branch in the Orbit repository
+1 for explicitly marking the source version of the lib
differently than the final lib. It's important for
consumers to know what original lib the bundle was
build from exactly. i.e.
org.foo.bar_1.0.0.RC2_v200801291200
-->
org.foo.bar_1.0.0_v200801291200
should work with the standard ASCII character set where
lowercase letters are considered "higher" than uppercase
letters so the "R" is considered earlier than the "v".
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: orbit-dev-bounces@xxxxxxxxxxx
> [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Kaegi
> Sent: Friday, January 25, 2008 6:49 PM
> To: Orbit Developer discussion
> Subject: Re: [orbit-dev] How to handle RC's?
>
> +1
>
> orbit-dev-bounces@xxxxxxxxxxx wrote on 01/25/2008 12:41:08 PM:
>
> >
> > > we should have a convention for the tagging of RC content
> such that
> > > when we release the official version the tag sorts higher than the
> > > RC. Perhaps just tag with v<date>-RCx. When the official
> release is
> > > tagged we would remove the RCx and make sure the date is
> incremented
> > > in the tag.
> >
> > I think this suggestion from Tom makes the most sense -- minimize
> > branches unless "really different".
> > Especially in cases where the official release is "expected soon".
> > If it's known it's going to be 6 months or a year before the
> > official release, then that might be a different matter, but
> > otherwise, _appended_ qualification to the qualifier is the
> way to go,
> IMO.
> >
> >
> >
>
> >
> > From:
> >
> > Chris Aniszczyk/Austin/IBM@IBMUS
> >
> > To:
> >
> > Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
> >
> > Date:
> >
> > 01/25/2008 12:35 PM
> >
> > Subject:
> >
> > Re: [orbit-dev] How to handle RC's?
> >
> >
> >
> >
> >
> >
> > I was just trying to keep things as close as to the
> workflow we already
> have.
> >
> > ie., branch for each version, in this case even an RC, ie.,
> v1_0_0_RC2
> >
> > For a bundle version, I'd imagine 1.0.0.RC2_qualifier will work.
> >
> > I'm just looking for agreement from the rest of the Orbit team so
> > the docs can be updated for this corner case. I already contacted
> > the author of the library and he wasn't in the mood to release a 1.
> > 0.0 before the Ganymede IP deadline cut off ;p
> >
> > Cheers,
> >
> > ---
> > Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.
> > blogspot.com | +1.860.839.2465
>
> >
> > From:
> >
> > Thomas Watson/Austin/IBM@IBMUS
> >
> > To:
> >
> > Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
> >
> > Date:
> >
> > 01/25/2008 10:56 AM
> >
> > Subject:
> >
> > Re: [orbit-dev] How to handle RC's?
> >
> >
> >
> >
> >
> >
> > I see there is a lack of response to this message but I think it is
> > because the issue is not clear (at least not to me :)
> >
> > Why have a branch for an RC? Shouldn't we keep putting 1.0.0 RC
> > builds into the v1_0_0 branch until the official release of 1.0.0?
> > The final release will get tagged and the latest version from orbit
> > should include the proper tag in the qualifier to ensure
> the versiongets
> rev'd
> >
> > Are you suggesting that the qualifier of the RC's need to somehow
> > mark that the version is an RC and not the real release? If that is
> > the case we should have a convention for the tagging of RC content
> > such that when we release the official version the tag sorts higher
> > than the RC. Perhaps just tag with v<date>-RCx. When the official
> > release is tagged we would remove the RCx and make sure the date is
> > incremented in the tag.
> >
> > The other option is to only release official releases into Orbit.
> > I'm not sure if that is an option.
> >
> > Tom
> >
> >
> >
> > [image removed] Chris Aniszczyk---01/24/2008 11:02:09 AM---Anyone
> > have opinions on how to handle RC's for Orbit bundles. For example,
> > imagine a scenario where we have some Library X... w
> >
> > [image removed]
> > From:
> >
> > [image removed]
> > Chris Aniszczyk/Austin/IBM@IBMUS
> >
> > [image removed]
> > To:
> >
> > [image removed]
> > orbit-dev@xxxxxxxxxxx
> >
> > [image removed]
> > Date:
> >
> > [image removed]
> > 01/24/2008 11:02 AM
> >
> > [image removed]
> > Subject:
> >
> > [image removed]
> > [orbit-dev] How to handle RC's?
> >
> >
> >
> >
> >
> >
> >
> > Anyone have opinions on how to handle RC's for Orbit bundles. For
> > example, imagine a scenario where we have some Library X... where
> > the version was 1.0.0 RC2.... how would you want to handle this...
> > besides emailing the author and saying when 1.0.0 was coming out?
> >
> > v1_0_RC2 as a branch with the bundle version as 1.0.0.qualifier?
> >
> > v1_0_0 as a branch with the bundle version as 1.0.0.qualifier when
> > 1.0 comes out? That should guarantee that the version would get
> > rev'd probably.
> >
> > Thoughts?
> >
> > Cheers,
> >
> > ---
> > Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.
> > blogspot.com | +1.860.839.2465
> _______________________________________________
> > orbit-dev mailing list
> > orbit-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/orbit-dev
> > _______________________________________________
> > orbit-dev mailing list
> > orbit-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/orbit-dev
> >
> > _______________________________________________
> > orbit-dev mailing list
> > orbit-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/orbit-dev
> > _______________________________________________
> > orbit-dev mailing list
> > orbit-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/orbit-dev
>
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev
>
