mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Stable update process (was Re: mxe for window


From: Volker Grabsch
Subject: Re: [Mingw-cross-env-list] Stable update process (was Re: mxe for windows 7 (64 bit))
Date: Wed, 24 Jul 2013 09:43:39 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Tony Theodore schrieb:
> On 22/07/2013, at 7:12 PM, Volker Grabsch <address@hidden> wrote:
> 
> > However, for this release I think it's sufficient to name it 2.23
> > and to make it public on platforms like Freecode.com and others.
> > The last release was more than a year ago, so the release will
> > give us more than enough attention.
> 
> Did you previously announce releases on the mingw.org mailing list? 
> Subscribers of that list (and now mingw-w64) would likely be interested in 
> mxe, but I'm not sure if it's appropriate.

No, I don't remember announcing anything on the mingw.org ML,
but I think this is a good idea!

Maybe ask politely if this announcement is appropriate, and
if they don't like it, simply don't announce the future
releases there.

> > Or, maybe this way of thinking is already obsolete, as nobody
> > cares about version numbers anymore? Not sure.
> 
> Let's see what happens in the next six months. If we're able to do frequent 
> updates, we could drop the version numbers and simply announce "Stable 
> Release yyyy-mm".

Yes, that kind of versioning scheme is also good.
Some distros do that, while others stick to classic
version number.

> You mentioned earlier that version numbers also imply a tag/branch - let's 
> see if any new users ask how to obtain a specific version.

As I said before, I think it's more likely that people
want a specific commit, which is not necessarily the
first commit of that release. But let's wait for the
demand and decide then.

> The only other process question is release criteria. The open issues at the 
> moment are outdated native versions and a strange edge case with cmake's hdf5 
> detection. The former is well know, and the latter can be fixed in stable at 
> a later date (since nothing depends on the affect packages itk and vtk6) - I 
> think this release is ready to go.

I fully agree. Let's start the release.


Regards,
Volker

-- 
Volker Grabsch
---<<(())>>---



reply via email to

[Prev in Thread] Current Thread [Next in Thread]