Allow the part to be defined on the command line

[desdrury]

Hi,

Firstly, I think bump version is awesome. It solves a lot of problems I have had with versioning in the past. However, there is one capability I wish it had. That is to be able to define the value for the part on the command line, i.e.

$ bumpversion build=$BUILD_NUM

So in this case it would use the provided value rather than increment an existing value.

I ask for this as it would make my workflow much easier. Here's my workflow.

• Once I have finished developing some code I use Bumpversion to increase the value of either the major, minor or patch. If there was a build number previously then it is removed.
• Bumpversion does the git checkin.
• Bamboo sees the newly checked in code. It runs a build job which checks the code out to a local workspace.
• Bumpversion is called by Bamboo with the 'build=$BUILD_NUM' argument.
• If the build succeeds then Bamboo does a Git checkin and deploys the built artefact to Nexus.

I hope this makes sense?

Cheers.

Des

[peritus]

Sounds like a reasonable request, will think about it the next time I'm sober (approx. Tuesday).

Did you see the support for environment variables in template strings in the README?

Sent from my pocket calculator

On 17 Jul 2014, at 06:27, desdrury notifications@github.com wrote:

Hi,

Firstly, I think bump version is awesome. It solves a lot of problems I have had with versioning in the past. However, there is one capability I wish it had. That is to be able to define the value for the part on the command line, i.e.

$ bumpversion build=$BUILD_NUM

So in this case it would use the provided value rather than increment an existing value.

I ask for this as it would make my workflow much easier. Here's my workflow.

Once I have finished developing some code I use Bumpversion to increase the value of either the major, minor or patch. If there was a build number previously then it is removed. Bumpversion does the git checkin. Bamboo sees the newly checked in code. It runs a build job which checks the code out to a local workspace. Bumpversion is called by Bamboo with the 'build=$BUILD_NUM' argument. If the build succeeds then Bamboo does a Git checkin and deploys the built artefact to Nexus. I hope this makes sense?

Cheers.

Des

\ Reply to this email directly or view it on GitHub.

[desdrury]

Hey,

I’ll be hoping that you only have a minor hangover before being sober again ;-)

I did see the support for environment variables in the template strings, and it brought me so close to what I was after it was almost perfect. The problem arose when doing a bump when the environment variable was not set, i.e. when I’m developing. The variable works perfectly on the Bamboo build side though.

Cheers.

Des

On 18 Jul 2014, at 5:05 am, Filip Noetzel notifications@github.com wrote:

Sounds like a reasonable request, will think about it the next time I'm sober (approx. Tuesday).

Did you see the support for environment variables in template strings in the README?

Sent from my pocket calculator

On 17 Jul 2014, at 06:27, desdrury notifications@github.com wrote:

Hi,

Firstly, I think bump version is awesome. It solves a lot of problems I have had with versioning in the past. However, there is one capability I wish it had. That is to be able to define the value for the part on the command line, i.e.

$ bumpversion build=$BUILD_NUM

So in this case it would use the provided value rather than increment an existing value.

I ask for this as it would make my workflow much easier. Here's my workflow.

Once I have finished developing some code I use Bumpversion to increase the value of either the major, minor or patch. If there was a build number previously then it is removed. Bumpversion does the git checkin. Bamboo sees the newly checked in code. It runs a build job which checks the code out to a local workspace. Bumpversion is called by Bamboo with the 'build=$BUILD_NUM' argument. If the build succeeds then Bamboo does a Git checkin and deploys the built artefact to Nexus. I hope this makes sense?

Cheers.

Des

\ Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

[peritus]

On second thought, this sounds reasonable (and was on my TODO list for some time, apparently).

I experimented with the current feature set as well with two config files (one for manual bumping, one for bamboo-bumping in your case), but that isn't as elegant.

Let's do this!

[desdrury]

Awesome!! That's great news :-) Please let me know if there's anything I can do.

Sent from my iPhone

On 25 Jul 2014, at 1:38 am, Filip Noetzel notifications@github.com wrote:

On second thought, this sounds reasonable (and was on my TODO list for some time, apparently).

I experimented with the current feature set as well with two config files (one for manual bumping, one for bamboo-bumping in your case), but that isn't as elegant.

Let's do this!

— Reply to this email directly or view it on GitHub.

[keimlink]

Does anyone work on this? Resolving this issue would make it possible to maintain PEP 440 compatible version identifiers (see #77).