maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Cooke <fred.co...@gmail.com>
Subject Re: Releases, Continuous Delivery and the Future
Date Mon, 15 Dec 2014 02:50:23 GMT
OK, well, classifiers works for me, then. It certainly seems like SNAPSHOTs
are  not the go-forward plan, at least, without your fix.

Is it true that you can't use 4 part versions with Maven without confusing
some logic that is hard coded to look for 1.2.3 rather than
N.N+1.N+2....N+M ? If not true, you could just step up to 4 and use up
minor minor steps.

Fred.

On Mon, Dec 15, 2014 at 3:11 PM, Jason van Zyl <jason@takari.io> wrote:

> A further definition of a qualifier is that it applies to all artifacts in
> a multi-module project (MMP). Unfortunately, at present, SNAPSHOTs are
> fundamentally flawed in that all artifacts produced in an MMP do not get
> the same timestamp. Each artifact gets its own which makes it impossible to
> refer to the MMP with a single version. This is highly problematic and was
> certainly a design oversight 10 years ago.I have code that remedies this
> but it's only one aspect of moving toward continuous delivery in that all
> builds produced at all times need to be releasable. So in the builds that I
> work on everything required for a release is enabled including source JAR
> generation and any checks. I have had customers in the past that went
> through all sorts of contortions to collect all the various snapshot
> versions for a release to mimc something like CD but it's certainly not
> ideal.
>
> On Dec 14, 2014, at 8:44 PM, Fred Cooke <fred.cooke@gmail.com> wrote:
>
> > Thank ****/***, finally some movement in the right direction! :-D
> >
> > Please also try to remember that EVERY single one of your "users" is a
> > *developer* and should comprehend that a version is an arbitrary label
> on a
> > piece of software to be used to uniquely identify it. If not, they should
> > be educated.
> >
> > Thanks for putting some time into this. Qualifiers suit me fine. As long
> as
> > they're immutable, I'm happy.
> >
> > Another approach is: SNAPSHOTs until you're actually confident, then
> > release a real one, and if it sucks, release another post more snapshots.
> > This is the entire point of snapshot builds in the first place, right?
> Just
> > my 2c.
> >
> > /me goes back to lurking.
> >
> > Regards,
> >
> > Fred.
> >
> > On Mon, Dec 15, 2014 at 2:29 PM, Jason van Zyl <jason@takari.io> wrote:
> >
> >> Hi,
> >>
> >> The discussion keeps resurfacing about how we deal with failed releases
> so
> >> I'll summarize how I think it should ultimately be done as a starting
> point.
> >>
> >> I'll go over the cases we've encountered thus far:
> >>
> >> 1) The user case prefers non-disjunct sets of releases, or from our PoV
> >> re-used versions. I believe people are confused by missing versions and
> >> will always result in questions like "What happened to version X?",
> where X
> >> is a non-viable build. Not many people read release notes, will not
> >> self-serve and it will just be a lot of questions and confusion. The
> >> typical user doesn't care about the question of whether a particular
> build
> >> is viable or not. I think they naturally expect contiguous, increasing
> >> versions when they update to new versions of a product.
> >>
> >> 2) The tester case prefers new versions but has tolerated re-used
> >> versions. Testers for core only really have to deal with the binary
> >> distribution and if it gets thrown away there's not much chance of local
> >> repository inconsistency because the typical tester, who is not an
> >> integrator, isn't going to depend on the new core release for anything.
> >> Running 3.2.4 doesn't put anything related to 3.2.4 in your local
> >> repository.
> >>
> >> 3) The integrator case prefers new versions. Different content with the
> >> same version is a violation of our immutability philosophy and can cause
> >> issues. Even though this is very much contained at the moment let's be
> >> optimistic and believe we will have many integrators that will test
> >> pre-released versions. Igor is right in that it's not fun to keep track
> of
> >> this and why should the burden be placed on the integrator. The answer
> is
> >> it shouldn't.
> >>
> >> 4) The release manager case prefers new versions. I have typically
> reused
> >> versions because I believe 1) is true. It's a PITA to erase tags,
> shuffle
> >> issues around in JIRA, and reset the POMs. I would prefer to just move
> >> forward, but I have done it because the user confusion is not worth the
> >> small effort it takes me to clean up a few resources. One hour for me
> >> versus thousands of hours of confusion for all users. It's an easy
> >> calculation.
> >>
> >> Taking all these cases into consideration so that all participants are
> >> satisfied I think we ultimately want increasing and contiguous versions
> for
> >> users, testers and integrators while the release manager does not have
> to
> >> shuffle a bunch of resources around in the event of a non-viable build.
> >> What we want is a form of continuous delivery where a version like
> 3.2.4 is
> >> the version that we call it to the outside world (some refer to it as
> the
> >> marketing version) and the qualifier changes from build to build so we
> have:
> >>
> >> 3.2.4-qualifier
> >>
> >> And for simplicity's sake let's just say the qualifier is a build number
> >> so we end up with:
> >>
> >> 3.2.4-01
> >> 3.2.4-02
> >> ...
> >> 3.2.4-NN
> >>
> >> Every build is a complete build that can be released, and in the stream
> of
> >> builds that are produced we decide that one is good enough for public
> >> consumption. Nothing in the issue tracking or documentation needs to
> change
> >> as it's still referred to as 3.2.4. People who download the distribution
> >> aren't going to care what the exact versions say on the JARs but some
> >> education might be required to tell people that something like 3.2.4 is
> >> actually 3.2.4-05 if they want to refer to an artifact from 3.2.4. I
> don't
> >> think making aliases to the marketing versions are a good idea and
> wouldn't
> >> want to duplicate artifacts so that they can be referred to by the
> >> marketing version. People will just become accustom to knowing a
> qualifier
> >> is necessary to find the actual version.
> >>
> >> This is more how things work at Eclipse where if you look at something
> >> from Jetty:
> >>
> >>
> >>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.eclipse.jetty%22%20AND%20a%3A%22jetty-servlet%22
> >>
> >> You'll see that something like jetty-servlet 9.2.3 is actually referred
> to
> >> as 9.2.3.v20140905. Jetty seems somewhat inconsistent with respect to
> >> milestones but you get the idea. I think this works for all parties but
> >> especially users where say we all happen to write blog entries about
> 3.2.4
> >> and it fails twice and we actually release 3.2.6. This is just so
> confusing
> >> as anything that referred to 3.2.4 now really means 3.2.6 which is
> totally
> >> inconsistent. I think skipping failed versions from the users
> perspective
> >> like we are currently doing is just a recipe for a massive amount of
> >> confusion and wasted time. Moving toward a stream based approach with a
> >> marketing version and qualifiers for actual versions is really the only
> way
> >> it can work for everyone.
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> http://twitter.com/takari_io
> >> ---------------------------------------------------------
> >>
> >> To think is easy. To act is hard. But the hardest thing in the world is
> to
> >> act in accordance with your thinking.
> >>
> >> -- Johann von Goethe
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
>   -- Shakespeare
>
>
>
>
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message