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

[Tony Theodore]

On 21/07/2013, at 8:39 PM, Volker Grabsch <address@hidden> wrote:

> Tony Theodore schrieb:
>> That seems clear, the stable branch is both the changelog and download, and 
>> the release is the tested updates from master.
>> 
>> The only other minor thing is (in)significance of numbering. We'll end up 
>> with a "2.99" at some stage, and major.minor isn't really applicable. This 
>> will be the 30th release, should we call it "Release 30" and just increment 
>> it from there? (maybe adding a yyyy-mm?)
> 
> After 2.9 came 2.10, so I don't see a problem with 2.99 being
> followed with 2.100.
> 
> This will be the 29th (1.0-1.4 and 2.0-2.23) release in total,
> but the 24th release of MXE as a Makefile.
> 
> The major version is meant to indicate backwards-incompatible
> changes to the public interface. While this is mostly clear
> for libraries and command line tools, it is of course fuzzy
> for a project like MXE. I decided to switch from 1.x to 2.x
> when I changed the main script from a shell script to a Makefile,
> which was quite a huge change in the "public interface" of MXE.

Sounds good, something like adding dynamic/shared builds would possibly 
constitute such a change - especially if we want to run them side-by-side.

>>> 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:
>> 
>> Thanks, I've been testing the fast-forward and it's been failing due to that 
>> missing merge-from-stable. I didn't realise cherry-picks have different 
>> checksums, it works smoothly now.
> 
> Indeed, the current branch concept works well if you make
> a fix to stable, then merge it into master.
> 
> However, if some fix happens to be commited to master first,
> cherry-picking to stable is not enough. You'll still have to
> make a merge from stable into master afterwards.
> 
> (Of course, we could also have another branching concepts,
> which says that everything goes into master, and changes
> to stable are cherry-picked-only. This would also work well,
> but also has its own sets of drawbacks.)

The first two seem to cover most scenarios, just have to remember the 
merge-from-stable. With more frequent stable updates, the need to cherry-pick 
should be reduced.

[…]

> In the old days, when all metadata was in the *.mk files, I always
> had a bad feeling of two entries: full package name and package
> project website. Those two things were only used for the generated
> documentation, and the whole MXE would have worked perfectly without
> those.

Indeed, I see that as a handy feature :)

> So having those "hard coded" in the docs actually feels "more
> clean" to me. :-)

The new implementation ensures consistency with minimal overhead - this is much 
better than my "eventually consistent" approach.

Cheers,

Tony