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

[Tony Theodore]

On 18/07/2013, at 8:54 PM, Volker Grabsch <address@hidden> wrote:
[…]
> 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

Thanks - all introduced by me I see, I'll keep an eye out for that in the 
future.

[…]
>> 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?

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?)

> 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.

> 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?

I didn't get very far, my javascript is rusty, and the approach needs a package 
list (manually maintained or generated) as js can't glob a server directory. 
The more metadata that we move out of index.html, the more it feels like a 
mechanical list that should be generated.

I think I'd rather see all metadata back in the *.mk files, with the "List of 
Packages" in index.html being a link to (say) package-list.html that gets 
generated after every successful build (or not at all in master). This way, the 
"real" documentation doesn't get hundreds of updates, the "appendix" is always 
up to date, and the package files are self-contained.

Cheers,

Tony