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

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

+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