No, the next release should be 1.0 [pre] as planned
0voters
Right now is the longest period of time that Crystal hasn’t seen a release (0.35 was in Jun 2020).
Timeline plot: Image / Webpage
The reason for this seems to be that the next release is defined to be 1.0 and nothing else, but that important milestone is being pushed back because it’s not ready.
As far as I can tell, there is no significant downside to just making another 0.x release before it. The only thing is that Manas may be seen as backing out of their promise for 1.0. And, well, the VERSION file will have an inconsistency in git history.
I don’t think this release would delay 1.0, it’d just be a safer stepping stone on the way. Otherwise with a “big boom” release a lot can go wrong, and “pre-releases” don’t help much there. The latter would apply even if 1.0 was coming soon now. But in any case, many people are waiting for their desired language improvements to come out.
With this poll I hope to get some data regarding whether there is consensus on this. Otherwise all I see is occasional remarks from people wishing that there was a 0.36 release. Me definitely included.
Small incremental changes are preferable. I don’t mind the next release being called 0.36.0 or 1.0.0-pre, but I think enough PR’s have been added to cut another release.
How much extra work will go into a 0.36 release that could be used for 1.0 instead?
Are there any interesting new features/bugfixes/etc or is it mostly changes for the upcoming 1.0 ?
I don’t mind to wait, as I don’t know what features I would want that would be in 0.36
How much extra work will go into a 0.36 release that could be used for 1.0 instead?
The effort is the same. Releasing a new version is pretty simple. For the most part it’s automated.
Are there any interesting new features/bugfixes/etc or is it mostly changes for the upcoming 1.0 ?
Right now there are 291 PRs closed against the 1.0 milestone, which could be just 0.36.0. The difference between 0.35.1 and master is already huge: tons of bug fixes, performance improvements and changes.
I don’t mind to wait, as I don’t know what features I would want that would be in 0.36
The more we wait, the more master (or 1.0) and 0.35.1 will be different. That means that people using 1.0 will likely encounter a lot of breaking changes, which is not good. Also, people keep reporting the same issues to the project where these are already fixed: it’s just that they weren’t released. And as more time passes and more bugs are fixed, this will continue to happen.
When you work with git and you have a huge branch with lots of changes, instead of merging that to master and see how things go, you usually merge master into the branch and see how things are. Then if all is good you merge back to master which, at that point, is a no-op.
Similarly, if we release 0.36.0 and let that be for a while, and then release 1.0 with none, or very few, changes 0.36.0 would have already proven to be good and stable, and the same will be true for 1.0. And that’s the thing I feel we should do.
I’m definitely on board with a 0.36.0 release as it looks like there may be some changes that could affect Lucky. We’ve already seen 1 PR that broke Lucky requiring another PR to sort of patch that. It would be nice to get those in and really see what changes we have. I’d rather Crystal not release a “Cyberpunk 2077” 1.0 Plus, with all this talk of GSoC, maybe we’ll see all the last edges get polished for 1.0!
And lately a user named HertzDevil started sending a lot of excellent PRs that target the compiler, and right now there are still a bunch of open PRs. If we can get those merged for 1.0 then the release will be much more solid. So it will feel more 1.0 that way.
It looks to me like there are too many PR’s for a 1.0 release. Lots and lots of changes will inevitably lead to instability and bugs. They should be given some time to mature.
Let’s have a 0.36 then. It will help the community to catch up with latest improvement and changes in master better than if it’s released as 1.0-pre1.
But, in order to move forward with a 1.0 release. I would say to also release in a very short time a 1.0-pre1 that will be mainly 0.36 + deprecation drops.
1.0-preX series could accept bug fixes and docs improvements. It should not accept brecking changes, further polishing or even new big features. Otherwise again, the last 0.x series will have too much delta with 1.0.
After 0.36 is released, master will remain as 1.0-preX until 1.0 is tagged. This will push a hold in features but is a way for all to focus on a common goal. Othewise, master would receive features that should land in 1.1 while 1.0 is not released and people will find that confusing (this happen around 0.25 IIRC)
Agree to move forward with an incremental release.
I would love to see a v1 and maybe get NYTimes to buy in to start using it, but if the fear is that more bugs can cripple in then it is wise to move with 0.36
FYI, the first nightly advertised as 0.36.0-dev has been published and I removed the 1.0.0-dev because otherwise, although 0.36.0 is newer, the 1.0.0-dev was offered as latest nightly.
If that causes some issues because people expect 1.0.0-dev, an alternative solution would be to publish upcoming nightlies as both, 0.36.0-dev and 1.0.0-dev.
):
Plus, with all this talk of GSoC, maybe we’ll see all the last edges get polished for 1.0!
