metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: What do we want to bring to the first release of Apache MetaModel?
Date Mon, 29 Jul 2013 01:55:00 GMT
On Thu, Jul 25, 2013 at 2:10 PM, Kasper Sørensen <
i.am.kasper.sorensen@gmail.com> wrote:

> Re2013/7/25 Noah Slater <nslater@apache.org>
> >
> > On 24 July 2013 19:07, Kasper Sørensen <i.am.kasper.sorensen@gmail.com
> >wrote:
> >
> > > I also felt that having a release soon is a
> > > priority in order to show activity from the incubation perspective.
> > >
> >
> > Don't worry about getting the release out to satisfy some arbitrary
> > "activity" metric. We can demonstrate activity via mailing list posts,
> > commits, etc.
>
> OK then I guess we can have a little more patience.
>
> >
> >
> > > Maybe a snapshot (or other non-final) way of releasing would be good?
> Maybe
> > > my use of the word "release" wasn't entirely in line with what we can
> > > define as a "proper" release.
> >
> >
> > Aye. The word "release" is very special, so we need to be careful about
> how
> > we use it. There is no such thing as a "proper" release, as that implies
> a
> > less formal one. But the ASF makes no such distinction.
> >
>
> Read further down ...
>
> >
> > > What I had in mind is at least to make public
> > > a set of artifacts on the maven central, so that people can start using
> > > MetaModel with the org.apache namespace. Potentially well-knowing that
> > > there will be some breaking changes coming in the near future.
> >
> >
> > That's fine. But we need to call them snapshots, or nightlies, or builds,
> > or whatever. And when we talk about them, or link to them, we need to be
> > very clear with our language that these are not releases, they are not
> > meant to regular users, and should be downloaded and used by devs only.
> >
>
> ... further ...
>
> >
> > > Is that doable on short
> > > notice, and then we can rather plan a roadmap to a more official/final
> > > release?
> > >
> >
> > You could do that now, if you wish. Just bung some files in your web
> space
> > on people.apache.org. As long as you don't call them releases, or even
> hint
> > at the idea that they're releases, then everything should be fine.
>
> I would ideally want something we can publish on the maven central. No
> matter what we dub it (snapshot, build, release candidate etc.), but
> it should be there so we can start migrating projects that use MM to
> the new namespace. Maybe for a period only to prove that "it still
> works" (continuous integration etc.) and not necesarily that we've
> improved anything.


> Let me be concrete; I see for instance that commons-lang exist in the
> maven central under the seemingly "non final" version: 20030203.000129
>
> http://search.maven.org/#artifactdetails%7Ccommons-lang%7Ccommons-lang%7C20030203.000129%7Cjar
>
> To me this looks like a version name that identifies a build.
>
> Could we do a similar maven release of a build (consciously using the
> maven prefix here because it's the maven definition of a release to
> publish it to a repo :-)) to the central repo?
>

SNAPSHOTs would go to repository.apache.org, which people can point to if
they choose.  SNAPSHOTS should represent just a working build of any given
project and should only be used by downstream projects to detect and report
bugs as they impact their usage.

If we want to put something out there that represents an intermediate
state, but is more static (SNAPSHOTs change with every CI build usually),
then we should do an intermediate release.  3.99.x or 4.0.0-alpha, or
foo.bar.x.  What name any release has is completely up to us and should
only represent the community's agreement as to the sate of the software.

This type of release would count as a fully fledged podling release and
must comply with the basic legal compliance (no GPL dependencies, correct
license attributions, etc).  We don't have to have all branding items like
package names completed in order to do a release.


>
> >
> > --
> > NS
>

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