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

[David M Williams <david_williams@xxxxxxxxxx>]

> 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 version gets 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

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

From:	Chris Aniszczyk/Austin/IBM@IBMUS
To:	orbit-dev@xxxxxxxxxxx
Date:	01/24/2008 11:02 AM
Subject:	[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