RE: [orbit-dev] How to handle RC's?

[Chris Aniszczyk <zx@xxxxxxxxxx>]

I updated the wiki with notes on the
"RC case"

http://wiki.eclipse.org/Adding_Bundles_to_Orbit#Special_Detailed_Notes_on_the_RC_case

If people agree, give it a go and we'll
close the issue and we can get back to adding bundles ;)

Cheers,

---
Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.blogspot.com
| +1.860.839.2465

From:	"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
To:	"Orbit Developer discussion" <orbit-dev@xxxxxxxxxxx>
Date:	01/28/2008 07:36 AM
Subject:	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
> 
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev