moving hotfixes along a parallel SDLC

10 views
Skip to first unread message

Guy Matz

unread,
Oct 17, 2016, 9:44:25 AM10/17/16
to jenkins...@googlegroups.com
Hello!  I need to be able to bump version numbers between two different jobs, meaning that if job A runs, it should have a build number higher that job B, and if job B runs, it should have a build # higher than job A . . .  for example, job A may run 10 ten times and have a build number of 10.  Then job B will run and needs a build # of 11.  Job A wight run after than and needs a build # of 12.

Anyone know how to do this?  I *think* I need this because I am going to have parallel tracks in my SDLC:  my usual develop -> master and a new hotfix -> master SDLC being build by a separate job.  Do I need this?  Any better ideas out there?  This seems like a common enough problem that it's already been solved six ways to sunday . . .

Thanks a lot,
Guy

Björn Pedersen

unread,
Oct 17, 2016, 10:00:15 AM10/17/16
to Jenkins Users
Hi,

It could be done, but think about using  a better versioning scheme.  Using build numbers  from different jobs seems like a way to ask for trouble.

Take a look at:
  https://wiki.jenkins-ci.org/display/JENKINS/Version+Number+Plugin
  https://wiki.jenkins-ci.org/display/JENKINS/semantic-versioning-plugin
  https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin

Björn

Guy Matz

unread,
Oct 17, 2016, 10:28:50 AM10/17/16
to jenkins...@googlegroups.com
Yeah, sorry, I'm not actually suggesting bumping version #s is the way to go . . .  I was hoping that maybe I was approaching the problem the wrong way, and that someone had a better idea.  Thanks!!

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ff35676e-c537-493d-ab45-62a5ce42ca8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Baptiste Mathus

unread,
Oct 21, 2016, 1:04:06 PM10/21/16
to jenkins...@googlegroups.com

OK then let's go back to your original question. You say you"need to bump version numbers". I would guess this is actually not the root reason.

Why do you want to do that?

I mean: if they are different jobs, so probably for different things, why would want to do that?

It does indeed seem surprising to me at first sight.


Le 17 oct. 2016 4:28 PM, "Guy Matz" <guy...@gmail.com> a écrit :
Yeah, sorry, I'm not actually suggesting bumping version #s is the way to go . . .  I was hoping that maybe I was approaching the problem the wrong way, and that someone had a better idea.  Thanks!!

On Mon, Oct 17, 2016 at 10:00 AM, 'Björn Pedersen' via Jenkins Users <jenkinsci-users@googlegroups.com> wrote:
Hi,

It could be done, but think about using  a better versioning scheme.  Using build numbers  from different jobs seems like a way to ask for trouble.

Take a look at:
  https://wiki.jenkins-ci.org/display/JENKINS/Version+Number+Plugin
  https://wiki.jenkins-ci.org/display/JENKINS/semantic-versioning-plugin
  https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin

Björn


Am Montag, 17. Oktober 2016 15:44:25 UTC+2 schrieb Guy Matz:
Hello!  I need to be able to bump version numbers between two different jobs, meaning that if job A runs, it should have a build number higher that job B, and if job B runs, it should have a build # higher than job A . . .  for example, job A may run 10 ten times and have a build number of 10.  Then job B will run and needs a build # of 11.  Job A wight run after than and needs a build # of 12.

Anyone know how to do this?  I *think* I need this because I am going to have parallel tracks in my SDLC:  my usual develop -> master and a new hotfix -> master SDLC being build by a separate job.  Do I need this?  Any better ideas out there?  This seems like a common enough problem that it's already been solved six ways to sunday . . .

Thanks a lot,
Guy

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ff35676e-c537-493d-ab45-62a5ce42ca8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages