Re: Time to make a 5.2.0 release candidate?

[John Cowan]

I should mention that credit goes mostly to Alex Shinn and only some of it to me.  And yes, giving an explicit PLATFORM always works; this code is triggered only if PLATFORM is not defined.  As opposed to empty, in which case you get, as an artifact of how it's implemented, the good old "Set PLATFORM to one of these" text.

I would say the biggest risk is that you want a cross-build and forget to specify PLATFORM, in which case you get a native build.  Which isn't much of a risk.

On Sat, Dec 28, 2019 at 7:56 PM <address@hidden> wrote:

> Hi Peter,
>
> On 12/28/19 4:42 PM, Peter Bex wrote:
> > I think we're about ready to start the process for a 5.2.0
> > release.  What do you think?  Should we wait for the eggs
> > from #1655 to be fixed?
> >
> > What about the plaform auto-detection  patch?
>
> IMO we should try to fix the eggs but wait until after a new release to
> add the autodetection patch.
>

It would of course be better to fix the eggs first, but this might take time,
especially since some maintainers may not react instantly. We should
perhaps in general think about whether eggs broken by fixing bugs should
hold off the release process, particularly with a growing number of eggs.
#1655 fixed a genuine bug and the eggs that broke with this change took
advantage of this inconsistency, admittedly being tricked into believing
that adding arbitrary .c files to the command-line of csc would work. This
was simply overlooked in the design of the custom-build feature and
therefore caused the c-object egg components to be added.

For the autodetection patch: As I understand it, giving an explicit PLATFORM
should work in all cases, so not too much is lost, if particular systems give
trouble. Unless it takes serious effort to test all supported
Windows platform variants (which are the most difficult cases, IIRC) then I
think it would be a nice simplification.


felix