What you are describing is basically using "continuous" SNAPSHOT
dependencies.
Semantic Versioning is important for understanding API changes (and to
prevent such changes when not necessary). This could of course be computed
automatically, but there are also non-interface changes that a human needs
to indicate (e.g. change of .equals() javadoc)
It is very easy to set up Jenkins to build SNAPSHOT on any commit (e.g.
merge of Pull Request) and to deploy to the snapshot repository only if the
build and tests succeeded.
Approaches such as Nexus staging repositories and JFrog Artifactory's
release promotion can be used to add quality stamps ("stable versions") to
a separate repository.
On 1 May 2016 9:18 p.m., "Hohwiller, Jörg" <[email protected]> wrote:
> Hi there,
>
> I wanted to share some thoughs I had recently. Maven introduced a
> revolution to the Java world and made a really big step for dependency and
> build management. Open-Source projects are more productive with maven.
> However, in the last years DevOps showed up and projects start to
> continuously build releases in some cases with a fully automated build
> pipeline.
> When I look at open-source development around I see that we have great
> infrastructure with github and pull-requests, etc.
> But as a downside I also see slow and over-complex processes to get
> something released (see e.g.
> http://www.mojohaus.org/development/performing-a-release.html - wow that
> is not really lean).
> In order not to fingerpoint someone I will pick myself: I got a
> pull-request from someone for servicedocgen-maven-plugin that I maintain at
> mojohaus. I reviewed the PR and merged it. Unfortunately, I was very busy
> then and did not create a release for two month now. It might not take that
> much, but still too much. I want to question why do we need all this stuff
> and the votings, etc.
>
> So assume the following future vision for a maven project:
>
> * When a pull request passed (travis, coveralls, etc.) and gets merged a
> CI system automatically builds a release (no need to get PGP keys per
> developer just one setup once for the project CI). The release simply gets
> a timestamp as version-identifier (yyyyMMdd-hhmmss).
>
> * Now besides the project being responsible for quality (by having good
> tests and only accepting PRs after reasoable review) the community
> (artifact users) could also help and do additional quality assurance.
> Assume maven-central would become a collaborative platform where the users
> of artifacts could vote and label artifact releases. Add comments, link CVE
> or bug reports, etc. Vote +1/-1 on quality or security...
>
> * Still the project releasing the artifacts could label releases and
> associate minor/major release numbers to branches.
>
> In such case however dependencies would not point to a version like
> (4.2.1.RELEASE) but instead to 20160501-235901. In order to pick the right
> technical version you would lookup the collaborative meta data.
> I do not expect everybody to shout hurray to this rought idea. But I would
> be happy if people can think about it and may combine it with other ideas
> so we get even better in the future some day.
>
> See also
> https://dzone.com/articles/continuous-releasing-maven
> https://devopsnet.com/2012/02/21/continuous-delivery-using-maven/
>
> I would love to see that maven better supports flexible handling of the
> version for the development view while it could simply stay as it is for
> the consumer view. When I use variables in versions of POMs (and I do that
> in every project today e.g. in combination with flatten-maven-plugin) I
> always get warnings from Maven saying:
> [WARNING] Some problems were encountered while building the effective
> model for ...
> [WARNING] 'version' contains an expression but should be a constant.
>
> Still I see no clear picture how maven will adress these needs that
> obviously many developer seem to have.
> Issues like MNG-4161, MNG-624 and others were simply closed and not fixed.
> After just seeing that and levaing an angry comment, I was about to cancel
> this mail. However, I just decided to still send it but have little
> expectation that it will make any sense...
>
> Best regards
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
