Luxon: 2.0 plans

[icambron]

I want to make a number of breaking changes in 2.0:

1. Remove DateTime#until. That will let us strip out the DateTime -> Interval dependency and help with tree shaking.
2. Move toFormat() and fromFormat to their own top-level class (i.e. DateTimeFormat.fromFormat() returns a DateTime)
3. Move the presets to their own namespace to help with tree-shaking
4. Move all of the IE-supporting code into another module
5. Collapse all of the error types into one with different messages

I could use some feedback, especially on items 2 and 4.

[razor-x]

Since you are planning v2 now, does this mean Luxon will move to version 1 in a couple weeks? :grin: Mostly asking in reference to the semver spec:

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

[icambron]

Yeah, I'm going to release 1.0 first mostly as-is. Then make a bunch of changes and start 2.0.

[razor-x]

@icambron Just curious what is holding back 1.0. Our team is adopting Luxon and having it move to proper semver at 1.0 would really help us keep things stable. Can I offer any help to make this happen as early as today?

[icambron]

My hesitation is mostly that I want to almost immediately start pushing things into an incompatible 2.0 branch and I don't want to do a lot of backporting for fixes. So I wanted to get some bug fixes in before branching.

[razor-x]

I see, but if they are only bug fixes and not changes to the current API, you can still release 1.0.0 on master, work on your bug fixes, release 1.0.1, 1.0.2, 1.0.3 as you go, then when you are ready to start the 2.0 you can branch and start the incompatible work. Bumping to 1.0 does not mean you have to branch right away to 2.0.

[ericmorand]

I agree with @razor-x. As soon as an API is frozen and the docs are good enough, we can promote v1.0.0.

[icambron]

Well, regardless, it is released.

[benmccann]

@icambron what was your plan for when to start work on the incompatible 2.0 branch? I ask because I'm interested in some of the tree shaking improvements you mentioned :-)

[icambron]

@benmccann Soon! I want to do a little bit of groundbreaking on it. Waiting for a chunk of weekend time to do it.

[icambron]

There is now a 2.0 branch with one change in it, moving the formats out of DateTime. Unfortunately, I couldn't manage to make the formats shakable; a couple of things DateTime depends on depend, in turn, on the formats.

Important note: I will be continually rebasing that branch. That means that if you branch off of it, you might be in for a bad time (rebasing shared branches isn't very friendly of me). If you have a serious interest in contributing to it, LMK and we'll figure it out.

[stuta]

How can I add 2.0 branch? If I use "luxon": "https://github.com/moment/luxon#2.0" then it will ask for update every time when I use yarn upgrade-interactive --latest.

[benmccann]

I'd love to see the master branch start targeting 2.0

[icambron]

@benmccann That's going to be a bit, since I have yet to make many of the non-reverse-compatible changes. But more important that branches is releases. I can't do that either without later breaking semver. So the best I have for you is following the branch.

[jnst]

Could you please provide own type definition file like moment.js?
@types/luxon has not been updated.
https://www.npmjs.com/package/@types/luxon

[morajabi]

Excellent work! Just chiming to say, with https://github.com/tc39/proposal-intl-relative-time landing in Chrome, any plans for v2 or v3 to add in Luxon?

[icambron]

@morajabi doesn't have to wait until v2

[mastermatt]

@jnst @types/luxon has been brought up to date.
I would still like to see the types brought into this repo and published together though.

[icambron]

Going to close this ticket, since it's not super useful for my 2.0 planning anymore.