Release plan for 0.9.0

[max-sixty]

What's up?

0.9.0 is probably going to be our biggest ever release. It'll include:

• Module system
• Syntax changes — functions, tuples
• fmt
• Relation literals
• Regex search
• Integer division
  ...and so many more items (that would at the top of the release notes of any other release)!

Given @aljazerzen is responsible for the vast majority of these, I'll handle the release.

Questions:

• Are there any code changes that we should add before releasing? Are we at peace over not including NULLS LAST?
• Do we want to document the module system? Or we want to let it bake before officially releasing?
• What other docs are missing? I am happy to do these. Are there any features that are under-documented?

[aljazerzen]

Are there any code changes that we should add before releasing? Are we at peace over not including NULLS LAST?

I don't feel strongly about including it or not, I still think this is not a breaking change.

Do we want to document the module system?

We can document it, with "Experimental" banner.

What other docs are missing?

Probably the syntax changes have not been updated in the book. Also regex and integer division.

[eitsupi]

I think we should document that "The int div operator and mod operator use truncated division".

I'm in favor of introducing NULLS LAST now to update the DuckDB version.

[max-sixty]

Another thing we should do — update the language grammars for the new syntax

[max-sixty]

I'm in favor of introducing NULLS LAST now to update the DuckDB version.

TBC on my perspective:

• I was +0.2 on adopting NULLS LAST
• I was -1.5 on adopting NULLS LAST with the expectation to later revert it

We can continue discussing on #2622...

[aljazerzen]

Well then let's not adapt NULLS LAST, because we don't know yet what we'll do with #2622.

[max-sixty]

As discussed on the dev call — we'll change the float division in generic to just /, and the generic dialect will just be "simple SQL". I'll make the change and add some docs.

[max-sixty]

Indentation — I'll put a PR in with 2 and we can decide on what looks best!

[max-sixty]

Should this block on #2717 ?

[aljazerzen]

I think so.

[max-sixty]

Another blocker: #2781

[eitsupi]

As I wrote here #2717 (comment), how about releasing without waiting for the issue to be resolved?

[max-sixty]

As I wrote here #2717 (comment), how about releasing without waiting for the issue to be resolved?

Sorry for not having addressing this directly

I agree we should try and release 0.9.0 as soon as possible. But I think it would be a bad experience if it's not ready:

• For me count s"*" is quite alien for such a fundamental feature
• The grammars — vscode & the playground especially — are especially important. (Possibly we should add tests to them so we can't change the grammar in future without updating these...)

I do think it's a better project if we "can release at any time", so we should try and make changes somewhat atomically; so, for example, the grammars don't fall out of date with the language.
But I also think there are some big changes in 0.9.0, so it's more understandable in this instance...

[eitsupi]

@max-sixty Thanks for your reply.

Given that count is only one of many functions and that there are many queries that do not use count, I feel that a release should be made even if only count does not work ideally.

As for the grammar, I don't think it is actually part of the PRQL release.
That is, the documentation can be modified later by updating the web branch. prql-vscode can only be released after the release of prql-js.
(That said, I think it's important to update the grammar, so I did as much of that work as I could.)

[max-sixty]

That is, the documentation can be modified later by updating the web branch. prql-vscode can only be released after the release of prql-js.

This is true, yes.

But you don't think it would be confusing for the docs to be different from the version in VS Code? It's not so bad when it's a small change, but this will be very different, and so copying code between the two would be impossible.

Given that count is only one of many functions and that there are many queries that do not use count, I feel that a release should be made even if only count does not work ideally.

I'm open-minded if others agree — what do folks think?

(I also don't know how much work this would be to fix)

Thanks for pushing on this @eitsupi !

[eitsupi]

But you don't think it would be confusing for the docs to be different from the version in VS Code? It's not so bad when it's a small change, but this will be very different, and so copying code between the two would be impossible.

1. We can work on modifying prql-vscode after prql-js is released. It does not take weeks to complete that work. (By the way I already finished it. fix: update syntax for 0.9.0 prql-vscode#244)
2. I don't think broken syntax highlighting would prevent the release of the vscode extension. It is common for syntax highlighting to be broken, and a bug fix can be made later.

[max-sixty]

Yes, on reflection, I agree. I was associating the errors in VS Code with the syntax highlighter, but they actually come from the parser...

[max-sixty]

Thanks to @eitsupi for all the grammars!

Aside from the count s"*", is there anything else remaining?

Does #2857 need more work? I see we reopened it? Possibly because of the additional examples in the linked PR??

I can do a pass of the changelog.

[eitsupi]

@aljazerzen Any thoughts on this?

[aljazerzen]

Aside from the count s"*", is there anything else remaining?

For the count s"*" we have a plan, it just needs to be implemented.

Apart from that it would be nice to fix the windows overflow, but I don't hold that as a hard requirement.

[max-sixty]

@aljazerzen would you want us to release before the s"*"? I was thinking we would wait, but not sure how big the work is (and don't want you to feel like there's something hanging on you)

I agree the Windows issue doesn't need to block. I'm still confused by it FWIW!

[aljazerzen]

I'd rather wait for s"*", since that is a change to the std module and will be changed again soon. The change should not take too much effort, at most a week.

[aljazerzen]

I think we can release. Docs can be updated later on.

[max-sixty]

#3051 for post-mortem...