Re: [Mingw-cross-env-list] Stable update process (was Re: mxe for windows 7 (64 bit))

[Volker Grabsch]

Tony Theodore schrieb:
> On 24/06/2013, at 1:13 AM, Volker Grabsch <address@hidden> wrote:
> > Yes, I didn't find to the time to announce and to
> > coordinate one in the last months. Would be great
> > if someone else of the core team could take care
> > of that.
> 
> It's working smoothly on Debian and OSX for me now, so I've put out a call 
> for testers.

Great!

By the way, I had to fix some HTML issues that
accumulated in the docs (checking via http://validator.w3.org/):

https://github.com/mxe/mxe/commit/b657668b9ccef40ac953af0c4c8720b00319f807

> > Ideally, the stable branch would be upgraded at
> > least once per month, after a regular monthly
> > testing round.
> 
> How are we going to name/version these updates? I've started on the "release" 
> notes:
> 
> https://github.com/mxe/mxe/commit/d311959c2401e55e32143a77e8b65bbf2816d570
> 
> but got stuck with what to call the latest version and I'm not sure if we're 
> going to start using git tags or not (seem to have lost all the old mercurial 
> ones?).

That's a good question, and I think this has to be answered on
a higher level.

First of all, the last "classic" release was "2.21". It had a tag
and a tarball. Our current release "2.22" does not have a tarball.
In the old mercurial repository, it had a tag "2.22", but I think
I should not have created that, because we don't want anyone to
check out that old version. [1]  Rather, "Release 2.22" is by
definition our current stable branch.

So in short, I didn't create any Git tags because that would
confuse users into thinking it would actually make sense to
check out those, or that those versions are somewhat "more
stable" or "better tested" than the stable branch, which they
aren't.

I fixed the description of the old release 2.22 to better
reflect the actual situation, removing the "Download | Changelog"
header that didn't really make sense there anyway:

https://github.com/mxe/mxe/commit/c8a53cbd7ff95539fb09253f31b39f11a90610f0

I think we should keep with the word "Release", as this is
what other people expect and understand. In other projects,
this is even used in words like "rolling releases" which aren't
classic releases, either.

Also, using the word "Release" allows us to continue to
anounce our releases on sites like freecode.com (formerly
freshmeat.net).

I also think we should introduce all future "releases" with
a common paragraph such as:

| The *stable branch* was updated to the current development
| version after a thorough *testing phase*.

(where "stable branch" and "testing phase" are links)

As a proof-of-concept, I adjusted "Release 2.23" accordingly:

https://github.com/mxe/mxe/commit/fabef6cc30dd522639ef05595f27064812582c00

What do you think? Could that be a good solution?

Finally, I noticed that the latest changes to the stable branch
weren't merged into master, so I improved the "Branch Concept"
section to make the strategy more clear:

https://github.com/mxe/mxe/commit/835dac9718ca131b9f31387638435e20ee247dd6

I also performed the missing merge from stable into master:

https://github.com/mxe/mxe/commit/4bfd1ca749f3c39400158fc45e25dd49078728f3

One final thought: In the master branch we moved (among others)
the package version numbers from the package files into index.html,
which turned out to be not so great. We also had a plan how to
fix this. Maybe we should add that fix before the next release?
I think you wanted to have a look at that. Did you make any progress,
or should I take care of that?


Regards,
Volker


[1] Of course there is the use case that someone needs a fixed
    version of MXE, but even those people won't actually use
    that exact release, but almost certainly a later point in
    the stable branch, or even some specific point of the master
    branch. Those use a fixed git commit hash (or create a local
    branch from that commit), which is already a perfect solution
    for those use cases.

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