[cf-dev] release tagging ... to v or not to v

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[cf-dev] release tagging ... to v or not to v

Andrew Edgar1
Hi All,
 
One pet peeve of mine is the inconsistency of version tagging in the community github repos.  I think by looking it's about 50/50 whether there is a "v" or no "v" in the tag for each new release version.
 
Would it be possible to settle on some sort of standard?  Can we all use a "v" or all not use a "v" (I have no preference).  But when trying to write scripts that pull information from the repos it would be much easier if I didn't need a big if statement on whether to add this "v" or not :)
 
Anybody else have strong opinions one way or another.
 
CAPI, all the buildpack releases, routing-release    -  No 'v'
loggregator, statsd-injector-release, uaa, diego, garden-runc-release - Yes 'v'
 
Thanks,
 
Andrew Edgar
 
---
Andrew Edgar
Senior Software Engineer
Dept. D293, IBM Research & Development Boeblingen 
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: 49-7031-16-2868
E-Mail: [hidden email]
-------------------------------------------------------------------------------------------------------------------------------------------

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7789) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Jane Day
I share Andrew's peeve.
For the docs, we state that all version numbers should be prefaced with the lowercase "v". 


On Wed, Feb 28, 2018 at 2:21 AM, Andrew Edgar1 <[hidden email]> wrote:
Hi All,
 
One pet peeve of mine is the inconsistency of version tagging in the community github repos.  I think by looking it's about 50/50 whether there is a "v" or no "v" in the tag for each new release version.
 
Would it be possible to settle on some sort of standard?  Can we all use a "v" or all not use a "v" (I have no preference).  But when trying to write scripts that pull information from the repos it would be much easier if I didn't need a big if statement on whether to add this "v" or not :)
 
Anybody else have strong opinions one way or another.
 
CAPI, all the buildpack releases, routing-release    -  No 'v'
loggregator, statsd-injector-release, uaa, diego, garden-runc-release - Yes 'v'
 
Thanks,
 
Andrew Edgar
 
---
Andrew Edgar
Senior Software Engineer
Dept. D293, IBM Research & Development Boeblingen 
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: 49-7031-16-2868
E-Mail: [hidden email]
-------------------------------------------------------------------------------------------------------------------------------------------


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7791) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Zach Robinson
This was killing me the other day on cf-deployment.  I really prefer to exclude the 'v'.  It doesn't seem to add anything.
-Zach

On Wed, Feb 28, 2018 at 8:52 AM Jane Day <[hidden email]> wrote:
I share Andrew's peeve.
For the docs, we state that all version numbers should be prefaced with the lowercase "v". 


On Wed, Feb 28, 2018 at 2:21 AM, Andrew Edgar1 <[hidden email]> wrote:
Hi All,
 
One pet peeve of mine is the inconsistency of version tagging in the community github repos.  I think by looking it's about 50/50 whether there is a "v" or no "v" in the tag for each new release version.
 
Would it be possible to settle on some sort of standard?  Can we all use a "v" or all not use a "v" (I have no preference).  But when trying to write scripts that pull information from the repos it would be much easier if I didn't need a big if statement on whether to add this "v" or not :)
 
Anybody else have strong opinions one way or another.
 
CAPI, all the buildpack releases, routing-release    -  No 'v'
loggregator, statsd-injector-release, uaa, diego, garden-runc-release - Yes 'v'
 
Thanks,
 
Andrew Edgar
 
---
Andrew Edgar
Senior Software Engineer
Dept. D293, IBM Research & Development Boeblingen 
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: 49-7031-16-2868
E-Mail: [hidden email]
-------------------------------------------------------------------------------------------------------------------------------------------


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7792) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Mike Lloyd
I've run into this challenge a bunch. I also prefer to exclude the "v", makes parsing it with various tooling much easier.

On Wed, Feb 28, 2018 at 10:35 AM Zach Robinson <[hidden email]> wrote:
This was killing me the other day on cf-deployment.  I really prefer to exclude the 'v'.  It doesn't seem to add anything.
-Zach

On Wed, Feb 28, 2018 at 8:52 AM Jane Day <[hidden email]> wrote:
I share Andrew's peeve.
For the docs, we state that all version numbers should be prefaced with the lowercase "v". 


On Wed, Feb 28, 2018 at 2:21 AM, Andrew Edgar1 <[hidden email]> wrote:
Hi All,
 
One pet peeve of mine is the inconsistency of version tagging in the community github repos.  I think by looking it's about 50/50 whether there is a "v" or no "v" in the tag for each new release version.
 
Would it be possible to settle on some sort of standard?  Can we all use a "v" or all not use a "v" (I have no preference).  But when trying to write scripts that pull information from the repos it would be much easier if I didn't need a big if statement on whether to add this "v" or not :)
 
Anybody else have strong opinions one way or another.
 
CAPI, all the buildpack releases, routing-release    -  No 'v'
loggregator, statsd-injector-release, uaa, diego, garden-runc-release - Yes 'v'
 
Thanks,
 
Andrew Edgar
 
---
Andrew Edgar
Senior Software Engineer
Dept. D293, IBM Research & Development Boeblingen 
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: 49-7031-16-2868
E-Mail: [hidden email]
-------------------------------------------------------------------------------------------------------------------------------------------


--
Thanks,

Mike.

(on mobile, apologies for typos!)
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7793) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Eric Malm
As you might expect given that Diego tags the commit for final BOSH release version "X.Y.Z" as "vX.Y.Z", I have been in favor of including a leading "v" on version tags. Git tags have many applications, and a leading "v" is a short, relatively unambiguous indication that this subset of tags denotes final release versions. Happy to hear reasonable arguments on either side, though.

Best,
Eric


On Wed, Feb 28, 2018 at 10:02 AM, Mike Lloyd <[hidden email]> wrote:
I've run into this challenge a bunch. I also prefer to exclude the "v", makes parsing it with various tooling much easier.

On Wed, Feb 28, 2018 at 10:35 AM Zach Robinson <[hidden email]> wrote:
This was killing me the other day on cf-deployment.  I really prefer to exclude the 'v'.  It doesn't seem to add anything.
-Zach

On Wed, Feb 28, 2018 at 8:52 AM Jane Day <[hidden email]> wrote:
I share Andrew's peeve.
For the docs, we state that all version numbers should be prefaced with the lowercase "v". 


On Wed, Feb 28, 2018 at 2:21 AM, Andrew Edgar1 <[hidden email]> wrote:
Hi All,
 
One pet peeve of mine is the inconsistency of version tagging in the community github repos.  I think by looking it's about 50/50 whether there is a "v" or no "v" in the tag for each new release version.
 
Would it be possible to settle on some sort of standard?  Can we all use a "v" or all not use a "v" (I have no preference).  But when trying to write scripts that pull information from the repos it would be much easier if I didn't need a big if statement on whether to add this "v" or not :)
 
Anybody else have strong opinions one way or another.
 
CAPI, all the buildpack releases, routing-release    -  No 'v'
loggregator, statsd-injector-release, uaa, diego, garden-runc-release - Yes 'v'
 
Thanks,
 
Andrew Edgar
 
---
Andrew Edgar
Senior Software Engineer
Dept. D293, IBM Research & Development Boeblingen 
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: 49-7031-16-2868
E-Mail: [hidden email]
-------------------------------------------------------------------------------------------------------------------------------------------


--
Thanks,

Mike.

(on mobile, apologies for typos!)


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7794) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Adam Hevenor
We recently dropped the v on Loggregator releases. I can't say there was a ton of fore-thought put into this, but it seems more consistent with our other Loggregator supported releases. 
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7796) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Ruben Koster
In reply to this post by Andrew Edgar1
The v prefix works nicely with concourse git-resource tag_filter. 
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7798) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Marco Voelz

We also tag out bosh-openstack-cpi and bosh with a 'v' prefix. Here's what the github "draft a new release page" has to say about this

> Tagging suggestions

> It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4.

> If the tag isn’t meant for production use, add a pre-release version after the version name. Some good pre-release  versions might be v0.2-alpha or v5.9-beta.3.

 

I agree with Eric's view that this helps to distinguish git tags which are meant to be final releases from the ones that are just "tags that mean something else".

 

Warm regards

Marco

 

 

 

From: <[hidden email]> on behalf of Ruben Koster <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, 1. March 2018 at 09:50
To: "[hidden email]" <[hidden email]>
Subject: Re: [cf-dev] release tagging ... to v or not to v

 

The v prefix works nicely with concourse git-resource tag_filter. 

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7799) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] release tagging ... to v or not to v

Julz Friedman
+1 to Eric's view also. I like being able to (sort of) filter version tags.

Thanks,

On Thu, 1 Mar 2018 at 15:55 Marco Voelz <[hidden email]> wrote:

We also tag out bosh-openstack-cpi and bosh with a 'v' prefix. Here's what the github "draft a new release page" has to say about this

> Tagging suggestions

> It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4.

> If the tag isn’t meant for production use, add a pre-release version after the version name. Some good pre-release  versions might be v0.2-alpha or v5.9-beta.3.

 

I agree with Eric's view that this helps to distinguish git tags which are meant to be final releases from the ones that are just "tags that mean something else".

 

Warm regards

Marco

 

 

 

From: <[hidden email]> on behalf of Ruben Koster <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, 1. March 2018 at 09:50
To: "[hidden email]" <[hidden email]>
Subject: Re: [cf-dev] release tagging ... to v or not to v

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#7801) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Change Your Subscription
Group Home
[hidden email]
Terms Of Service
Unsubscribe From This Group

_._,_._,_