Decisions for LTS 2

[Michael Snoyman]

I'm cutting the release today for LTS 2. The goal is to have as few upper bounds in place as possible, especially for low-level packages that many will depend on. Unfortunately, not all upper bounds will be able to be removed. In some cases, we have the option to drop a package from LTS 2.0, and add it back in a point release once its dependency issues are resolved. Here's my plan of attack for the record; if anyone feels strongly, please respond soon, as the release is imminent.

• #415: I've already informed the maintainer that codex will be dropped due to the hackage-db upper bound. It can be added back later
• #442: This one is painful. blaze-builder is a core package, and version 0.4 is a significant change. All packages now compile with the newest version (after a number of pull requests from the Stackage team, notably Manny Borsboom). However, Snap has not relaxed its upper bounds, and therefore is holding back the release. Assuming they don't do a release in the next few hours, there are three options here (I'm leaning towards the first option):
  
• Release LTS 2 with blaze-builder 0.3
• Temporarily drop snap from Stackage
• Build the release with --allow-newer, and move ahead with 0.4. While this is tempting, it means that- until Snap relaxes the version bounds on Hackage- users won't be able to install it
• #467: diagrams hasn't upgraded to the newest lens. Only option is to drop the diagrams packages. Like Snap, I'm leaning towards being constrained to the old versions.
• #476: same situation with vector-space as #467
• #479: QuickCheck 2.8 can't make it in, too many packages require the older version
• #483: the problem is limited to the package with the restrictive bound, and a point release of that package can resolve the issue. No big deal to let this one stay in.
• #494: I'm going to disable benchmark dependencies for case-insensitive, postgresql-binary, and scientific
• #497: the new primitive would be very nice to get in. I've just sent messages to the two last maintainers, hopefully they'll get new versions out.
• #509: since the only person depending on srcloc is also the one with the upper bound, my inclination is to let it slide

If anyone has an opinion on these points, or updates about new releases that fix these problems, please let me know.

[Michael Snoyman]

Hi Daniel,

Thanks for sending this email, it's exactly that kind of communications issues that I hope we'll begin working out as a community as LTS becomes more solidified.

As I type, the LTS 2 release is being uploaded to the Stackage server, so the new version of diagrams unfortunately won't make it in. For future releases, we have two different approaches to dates:

1. Decide on dates in advance, announce them, and stick to them firmly, regardless of other packages

2. Make an announcement of a potential date, and allow it to slide by a certain amount depending on status of upstream packages

The assumption so far has been that we'd do (1), since that seems to be the standard for timed releases. And we don't want to repeat mistakes elsewhere of letting releases slip indefinitely. But I'm certainly open to exploring this space more. One thought that comes to mind would be have a "release window" instead of a release date, saying "LTS 3 will be release somewhere between July 1 and July 15" (perhaps with a smaller window). We'd still target the beginning of the window, but if there are extenuating circumstances, consider moving the date towards the end of the window. Does anyone have thoughts?

I'm also hoping that, over time, the LTS release schedule will become more regular (perhaps every 6 or 9 months), and packages can start trying to target those windows. For example, if I was planning on a major Yesod release, I'd try to target a month before the LTS release to get some testing in via Stackage Nightly before going into the LTS.

As for point release: yes, they would be very helpful. The current situation without a point release means that we're regularly constrained to older versions of the lens library, which makes life more difficult for other package maintainers who try to upgrade very quickly to the latest and greatest.

Michael

On Wed, Apr 1, 2015 at 11:43 PM Daniel Bergey <ber...@teallabs.org> wrote:

There's a new major release of Diagrams coming out, if not today, I
expect by the end of the week.  I haven't made a point release allowing
latest lens and vector-space mostly because I've been busy with &
anticipating this release.

I'd been hoping to avoid the point release entirely, and just do the
major release.  Would it help you if we do a final point release in the
1.2 series?  I expect I could get it out late tonight or early tomorrow.

I'll try to communicate better about such scheduling in the future.

Thanks,
Daniel

On 2015-04-01 at 08:27, Michael Snoyman <mic...@snoyman.com> wrote:
> I'm cutting the release today for LTS 2. The goal is to have as few upper
> bounds in place as possible, especially for low-level packages that many
> will depend on. Unfortunately, not all upper bounds will be able to be
> removed. In some cases, we have the option to drop a package from LTS 2.0,
> and add it back in a point release once its dependency issues are resolved.
> Here's my plan of attack for the record; if anyone feels strongly, please
> respond soon, as the release is imminent.
>

>    - #415: I've already informed the maintainer that codex will be dropped

>    due to the hackage-db upper bound. It can be added back later

>    - #442: This one is painful. blaze-builder is a core package, and

>    version 0.4 is a significant change. All packages now compile with the
>    newest version (after a number of pull requests from the Stackage team,
>    notably Manny Borsboom). However, Snap has not relaxed its upper bounds,
>    and therefore is holding back the release. Assuming they don't do a release
>    in the next few hours, there are three options here (I'm leaning towards
>    the first option):

>    - Release LTS 2 with blaze-builder 0.3
>       - Temporarily drop snap from Stackage
>       - Build the release with --allow-newer, and move ahead with 0.4.

>       While this is tempting, it means that- until Snap relaxes the version
>       bounds on Hackage- users won't be able to install it

>    - #467: diagrams hasn't upgraded to the newest lens. Only option is to

>    drop the diagrams packages. Like Snap, I'm leaning towards being
>    constrained to the old versions.

>    - #476: same situation with vector-space as #467
>    - #479: QuickCheck 2.8 can't make it in, too many packages require the
>    older version
>    - #483: the problem is limited to the package with the restrictive

>    bound, and a point release of that package can resolve the issue. No big
>    deal to let this one stay in.

>    - #494: I'm going to disable benchmark dependencies for
>    case-insensitive, postgresql-binary, and scientific
>    - #497: the new primitive would be very nice to get in. I've just sent

>    messages to the two last maintainers, hopefully they'll get new versions
>    out.

>    - #509: since the only person depending on srcloc is also the one with

>    the upper bound, my inclination is to let it slide
>
> If anyone has an opinion on these points, or updates about new releases
> that fix these problems, please let me know.
>

> --
> You received this message because you are subscribed to the Google Groups "Stackage" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stackage+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.