On Thursday, November 16, 2017 23:10 GMT, Stephen Connolly
wrote:
> Only use release versions for releases
>
> For any builds in between releases, always use a SNAPSHOT. If you don’t
> want to commit to a version (which it sounds like you don’t) then pick
>
On Thu 16 Nov 2017 at 21:10, Adam Hardy
wrote:
> On 16/11/17 20:40, Stephen Connolly wrote:
> > I think you’ll want to keep master with a version of at least SNAPSHOT or
> > 1-SNAPSHOT and wholesale replace it with the real build version number on
> > the CI server
On 16/11/17 20:40, Stephen Connolly wrote:
I think you’ll want to keep master with a version of at least SNAPSHOT or
1-SNAPSHOT and wholesale replace it with the real build version number on
the CI server and just have that version in the tag.
The issue with using release versions on master is
On Thu 16 Nov 2017 at 13:26, ahardy42 wrote:
> V. interesting, thanks.
>
> I'm using TeamCity so controlling an infinite loop using trigger configs
> should be easy.
>
> However I don't want to use snapshot versioning at all, so the
> maven-release-plugin is
V. interesting, thanks.
I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.
However I don't want to use snapshot versioning at all, so the
maven-release-plugin is essentially not the right tool for the job.
These projects are microservices so every code
V. interesting, thanks.
I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.
However I don't want to use snapshot versioning at all, so the
maven-release-plugin is essentially not the right tool for the job.
These projects are microservices so every code
I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.
I don't want to use snapshot versioning at all.
These projects are microservices so every code commit is a release
candidate. My goal is to get maven to increment the build number on each
build - the build
On Wed 15 Nov 2017 at 18:11, Arnaud bourree
wrote:
> Hi,
>
> I like your blog post, but I need some clarification.
>
> On line 19, your pipeline snippet calls maven without goals !
> 1/ Does it means: release:prepare goal?
The line is very long, scroll horizontally
Hi,
I like your blog post, but I need some clarification.
On line 19, your pipeline snippet calls maven without goals !
1/ Does it means: release:prepare goal?
2/ In your idea, do we add our project maven build lines before line 22? I
order to take decision after some automatic tests validation.
On Sun 5 Nov 2017 at 11:31, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
>
> On Fri 27 Oct 2017 at 23:28, Laird Nelson wrote:
>
>> On Fri, Oct 27, 2017 at 1:58 AM ahardy42
>> wrote:
>>
>> > How can I tell maven to increment the
On Fri 27 Oct 2017 at 23:28, Laird Nelson wrote:
> On Fri, Oct 27, 2017 at 1:58 AM ahardy42
> wrote:
>
> > How can I tell maven to increment the version and commit the edited pom
> > without the CI platform seeing the commit and kicking off
On Fri, Oct 27, 2017 at 1:58 AM ahardy42
wrote:
> How can I tell maven to increment the version and commit the edited pom
> without the CI platform seeing the commit and kicking off again in an
> infinite loop?
Indeed. If you just use the maven-release-plugin,
Hi,
On 26/10/17 19:31, ahardy42 wrote:
The projects I'm working on are migrating towards a micro-services
architecture and my aim is to find a way to implement:
- auto-increment the version number
see my comments later ...
- semantic versioning (3.1.99, 3.1.100, 3.1.101 etc)
Just a
The projects I'm working on are migrating towards a micro-services
architecture and my aim is to find a way to implement:
- auto-increment the version number
- semantic versioning (3.1.99, 3.1.100, 3.1.101 etc)
- using the maven pom version as the master or source version number
- running
14 matches
Mail list logo