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

[Volker Grabsch]

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.

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

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

Yes, it is a pity that we can't simply iterate over all *.mk files
from JavaScript. But having a "static" package list in index.html
has an important advantage: It works out of the box without any
generator and with disabled JavaScript. So I think our current
"hybrid" approach (index.html + *.mk) is not that bad, it just
has to be tuned a bit:

If we move the version number from index.html back to the *.mk
files, all those small commits will vanish.

The JavaScript then has a quite easy job to just "fill in" the
version numbers into the table. On disabled JavaScript, you still
see the whole package list, just without version numbers.

The index.html would only change when a package is added or removed,
but not when it is upgraded. This is okay, I think, because adding
or removing a package actually warrants a documentation change.
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. So having those "hard coded" in the docs actually feels "more
clean" to me. :-)

What do you think of that? Should I provide an implementation of
this proposal?


Regards,
Volker

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