Release 0.3

[adamgundry]

I propose MondayWednesday as the release date and have updated things appropriately and uploaded tentative package candidates. The only significant change is that I propose to release optics-vl as 0.3 instead of 0.2.1. While in theory the latter is permissible, it doesn't seem worth deviating from the version numbering of the other packages at this point. Please shout if you disagree.

• https://hackage.haskell.org/package/optics-core-0.3/candidate
• https://hackage.haskell.org/package/optics-extra-0.3/candidate
• https://hackage.haskell.org/package/optics-th-0.3/candidate
• https://hackage.haskell.org/package/optics-0.3/candidate
• https://hackage.haskell.org/package/optics-vl-0.2.1/candidate

[arybczak]

One question: why do optics-extra and optics have upper bounds for optics-family packages set to <0.3.1, but optics-th and optics-vl have them set to <0.4?

Wouldn't it be better to set all of them to <0.4?

[phadej]

optics-extra could.

optics re-exports optics-core, optics-extra, and optics-thfunctionality so it must have tight bounds on them. This way we ensure that optics interface doesn't change without that optics version also changes. For example users don't need to also specify optics-core >=0.3.1 bound to ensure that some new combinator is present which was added in optics-core-0.3.1, but is available through optics re-exports.

[phadej]

optics-vl as 0.3 instead of 0.2.1.

I don't have strong opinion about that yet, but OTOH I do think that optics-vl is close to "done", so would rather let is have whatever version it has now.

[arybczak]

What about bugfix releases? Would it be 0.3.0.1?

[phadej]

The build-depends: optics-core >=0.3 && <0.3.1 in optics-0.3 would accept optics-core-0.3.0.1 if such would be done. Though in practice such releases are often ones which have some inner changes to e.g. accommodate new version of a dependency (which optics-core doesn't really have).

If we would make any changes to .Internal changes, those must be minor releases. Then we'd need to make a revision for optics allowing new optics-core minor version too. That's the price for exposing internals in the first place. One reason is that CPP allows to case on three first version digits, also in practice if someone uses .Internal modules, it would be required to specify exact versions as ==0.3, which is impractical. optics-core <0.3.1 is a compromise - a same requirement as if you define orphan instances, e.g.

Personally I would rather consider Internal modules as a part of "stable" API, and simply don't change them - just advice to avoid them if one could. Because I don't think that other packages which use internal modules would use stricter upper bounds in their dependency definitions, so if we actually change something, we'll break them. But that's another issue.

[adamgundry]

If we do this, then the lower-bound on optics-core dependency have to be optics-core >=0.3 too. Morally.

Why?

optics-0.2.1 is IMHO better because if someone is "stuck" with optics-core-0.2 they could use optics-vl-0.2.1.

Or to put it differently. We could release the current status of optics-vl with optics-core <0.3 bound still, without releasing optics-0.3 - it's standalone. And later when optics is released, the we can make revision to allow optics-0.3

TL;DR it would be better if optics-vl and optics-core / optics-extra / optics version numbers (and release cycles) are decoupled. The more they drift from each other the less confusion there will be.

EDIT: it might be (in theory, more applicable to optics-sop) that one would be forced to make major release of optics-vl or optics-sop due changes in non-optics (i.e. generics-sop-0.6)

Okay, you've convinced me. I was thinking it would lead to much confusion if we had inconsistent numbering between e.g. optics-core / optics-extra / optics, but that doesn't necessarily apply to optics-vl or other packages. So I'll revert to releasing optics-vl-0.2.1.

One question: why do optics-extra and optics have upper bounds for optics-family packages set to <0.3.1, but optics-th and optics-vl have them set to <0.4?

Wouldn't it be better to set all of them to <0.4?

optics-extra could.

I don't think so, because Optics.Indexed re-exports modules from optics-core, so its API depends on the optics-core minor version.

How does this sound as a summary/policy for future releases?

• optics-core, optics-extra and optics are all "coupled", i.e. they are always released together with the same minor version, and have bounds that require the same minor version. They may have bugfix releases independently, but only if there are essentially no API changes. (Perhaps one day they will all be one package using multiple public libraries.)
• optics-th can have looser bounds on optics-core, but optics must specify a minor version bound on optics-th. (Should it have its own version numbering/release schedule, or should it match optics?)
• optics-vl is released independently on its own schedule, and usual PVP rules apply.

[phadej]

I don't think so, because Optics.Indexed...

Good point. I missed that.

Your summary/policy is good. About optics-th: Optics.TH is re-exported in optics, so I'd say all four (optics-core, optics-extra, optics-th and optics) are "coupled".

[phadej]

It's somewhat expected that optics-th would change mostly due template-haskell changes (hopefully). Then it's IMHO ok to have

If we start with all four being 0.3, there is an addition in optics-core which propagates:

optics-core-0.3.1
optics-extra-0.3.1
optics-th-0.3
optics-0.3.1

and then if change occurs in optics-th we'll do:

optics-core-0.3.1
optics-extra-0.3.1
optics-th-0.3.2
optics-0.3.2

Which is, all four packages would share the major series, and "minor version counter", but we could avoid re-uploading essentially the same package with another version.

I think that would be useful, even requires to be a bit more careful, because libraries I maintain depend on optics-core and optics-extra only, so avoiding new version numbers will keep build caches warm.

I must admit, I'm annoyed when e.g. new release of distributive causes cascade rebuilding lens, or dlist busting aeson caches. Sometimes the releases are unavoidable, sometimes they are.

OTOH, those are theoretical concerns. optics is not moving with even release every month pace, and it is unluckily it would, so above can be simplified if the release pace constraint is true.

EDIT: yet Andrzej just made a change to optics-th which I guess could be 0.3.1 if it doesn't make it to 0.3 :)

[adamgundry]

I think this is basically ready, though I need to re-upload optics-vl. But @arybczak would you prefer to hang on a little longer to land your optics-th changes?

[arybczak]

@arybczak would you prefer to hang on a little longer to land your optics-th changes?

That would be lovely. It should be ready tomorrow.

[phadej]

Let us have a timeout with #313 and #314. I don't like "let's get them in quickly to get them into the release". Those are famous last words.

I'm unhappy that 0.3 release is delayed, but let us do stuff properly and not hurry it. At some point we just have to leave stuff out of the releases. I propose it's these two which we wait for, and everything else is just have to stay out.

The lack of GHC-8.10 compatible release is very unfortunate. For the future we should not bundle feature and compatibility changes into the same release, if similar scope creep is to be expected.

We could made optics-core-0.2.0.1 with needed one line change (https://gitlab.haskell.org/ghc/head.hackage/-/blob/master/patches/optics-core-0.2.patch) for GHC-8.10, and then there wouldn't be any time pressure. Maybe we just should still make optics-core-0.2.0.1 and wait until the dust settles on the rest of the optics? (optics-th needs changes too, but optics-core and optics-extra would allow some immediate downstream libraries to add GHC-8.10 support - there is cascade effect).

[arybczak]

I propose we include #314 and postpone #313 until next release.

#314 is trivial, #313 not so much.

[arybczak]

Now I think that #313 is alright to go in as it fixes a few bugs. I thought there's going to be some issues with it, but it turned out alright.

[adamgundry]

I've boldly merged #313, updated the changelogs and will release soon unless anyone objects.