Pending Merge Requests

[Faré]

If we can have only one of these changes in, I'd like !59, because it
fixes bundles on ECL on platforms that can't link libraries from
libraries (is that what makes it fail on Mac?). It's not a regression,
though, so unless Daniel K says it's urgent we can wait for the next
release.

!60 is a bug fix for people using logical pathnames, i.e. asking for
trouble. I would be nice, but not indispensible.

!61 is still a WIP pending review by Daniel K. It's me dropping the
sponge on trying to make load-bundle-op an implicit default at all on
ECL — but maybe that's not what Daniel K wants, and he wants it to be
a non-default implicit setting, rather than either a default implicit
setting or something you only get explicitly. I don't think it's
urgent.

PS: For our readers, these numbers refer to entries on gitlab:
https://gitlab.common-lisp.net/asdf/asdf/merge_requests/

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Democracy is the theory that the common people know what they want,
and deserve to get it good and hard. — H. L. Mencken

On Mon, Dec 12, 2016 at 1:58 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> I would very much like to get 3.2.0 released, but I am starting to feel
> like we have a Zeno process here.  Merge requests are appearing as fast
> as they are merged.
>
> Currently pending for 3.2.0:
>
> !59
> Link objects only
>
> !60
> Fix bad-system-name for "logical" .asd pathnames
>
> !61
> Remove *load-system-operation*
>
> Which, if any, of these must be in our 3.2.0 release candidate?  I would
> like to freeze a release candidate, marking it as version 3.2.0, for
> people to play with for at least a week, before we push it into the world.
>
> I'd very much like to do this this week, since the holidays are coming
> up when people's minds will turn to other things than testing new ASDF
> versions.
>
> I can pretty much guarantee that if the answer to the above is "we need
> all three," we are talking a 2017 release, instead of finishing this
> year, because of limitations on my available testing cycles in the
> remainder of 2016.
>