add a news article for the 22.03 release highlights #3
Conversation
|
Also, what do you think about splitting each of these into separate articles? I could probably fill an entire article with submodule stuff (or basically copy/paste the PR description from it), and I think it makes sense to split them up based on features for readability-sake too. We could probably add some |
If we have enough content then sure, I'd still make a larger annoucement and then link out to individual items. Might make sense to stagger the posts over a couple of days or weeks. Not everything needs it's own article though: https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html |
|
I think I'm going to back-peddle on this for now 😅. We can do a shorter text-only highlights section in the changelog and link out to posts if they exist for a feature. In the future I'd like to try making some write-ups for highlight features as they're merged so I can get more familiar with them (like DAP) and also hype the next release. I might swing back around to DAP and a submodules write-up as time allows |
|
Ok back-peddling on the pack-peddle. I think this is in decent shape and we should be able to just link to it from the changelog. I've updated that PR to point at the eventual link for this article |
| +++ | ||
|
|
||
| Ranging from small quality-of-life improvements and fixes to large features | ||
| and refactors, Helix 7 brings some exciting changes. |
There was a problem hiding this comment.
There's no point in keeping the 0. (https://0ver.org/). Might make more sense to bump to 1.0 though?
"If both you and someone you don't know use your project seriously, then use a serious version." / "If your software is being used in production, it should probably already be 1.0.0" We'll either number each release similar to browser releases, or use calendar versioning (https://calver.org/).
There was a problem hiding this comment.
There was a problem hiding this comment.
1.0 makes sense to me 👍
having .0 might come in handy if we ever need to make a patch release
There was a problem hiding this comment.
I think 1.0 now is still too new for helix given that there are no plugins and stuff yet so users should expect stuff to have breaking changes, so I guess 0. is good for now. But that's up to you to decide.
There was a problem hiding this comment.
There's always "one more thing". Plugins can easily be 2.0.
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.
also
0ver.org may list some auspicious names, but it's not a very good look. If you're having trouble picking a version, or are stuck asymptotically approaching an "actual" release, do yourself a favor and slap a CalVer on it.
(emphasis mine)
I'd be ok with a YY.0M(.MICRO) which was my aim before release but there were some folks complaining about calver around that time. Semver doesn't really mean much in applications since every new feature can be a "major (breaking) change" and calver works great for quick iterations (rust-analyzer uses it too)
There was a problem hiding this comment.
I would be ok with CalVer too. Seems like a good choice if we're aiming to do new releases regularly
There was a problem hiding this comment.
Nit: should we use YYYY.MM(.MICRO) (note the full year) instead ? Seeing v22 at first really left me confused as to how it jumped so far so fast.
| @@ -0,0 +1,219 @@ | |||
| {"version": 2, "width": 92, "height": 24, "timestamp": 1647631954, "env": {"SHELL": "/run/current-system/sw/bin/fish", "TERM": "xterm-kitty"}} | |||
There was a problem hiding this comment.
Should we have the casts under git-lfs? Although it is human readable it is not really that much human readable.
There was a problem hiding this comment.
They're not too large file-size-wise too, I think keeping them in the normal tree seems ok. We could disable diffs for them by setting
/static/*.cast -diff
in the .gitattributes so git diff will treat them as binaries
the-mikedavis
changed the title
the-mikedavis
changed the title
the-mikedavis
changed the title
Nothing too too fancy here, just some extra time in the limelight for some of the flashier features. I could use a little help with a asciinema cast for using DAP, I'm not very familiar with debuggers in general so I'm not too sure where to get started. @archseer could I bug you to record a
.cast?