New track request for the Ruby language

store
1

I hope to use track channel with ruby snaps.

Can you create a track versioned ‘2.5’, ‘2.4’ and ‘2,3’?

I’m a publisher of ruby snap.

3 Likes
2

I +1 this request. I validate that @hsbt is the current publisher and a core developer for ruby.

2 Likes
3

Oh my, Ruby is one of my favorite languages! I don’t get to use it much these days, though :frowning:

I haven’t followed Ruby in a while, but I wonder - are you sure there’s a valid use case for people to stay on 2.3 or 2.4, if 2.5 is the current stable release? Remember the main use case for tracks and programming languages is when the syntax changes in an incompatible way and there’s a significant code corpus deployed that makes upgrading unfeasible. Examples include DMD, Golang and node (the latter even has its own concept of LTS language releases).

For Ruby, the thing to consider is - if someone wrote code using 2.3, is that code likely to run unchanged under 2.5? (same situation for 2.4 → 2.5).

If code is likely to be runnable under 2.5, could you then please explain what you had in mind for using tracks?

I’d like to hear your thoughts before casting a vote, per Process for aliases, auto-connections and tracks we need two positive votes and there’s a waiting period of 7 days, but the time counts from the moment you made the request, so my questions won’t delay the final action in any case.

Cheers!

  • Daniel
4

AFAIK as I understand, they have developers that explicitly target features of a given point release.

5

Hi, roadmr.

Thakns for your comment.

The ruby core team are maintaining 3-branches now. Like this:

  • The current stable: 2.5
  • The old stable: 2.4
  • The only security fix branch: 2.3

In the next year, We will change their versions of branches with 2.6, 2.5 and 2.4. The new version of ruby has a bit of incompatible features.

If the users uses only one channel of snapcraft, They was enforced to upgrade the new version of ruby. We avoid that users encountered the incompatible features automatically in snapcraft.

6

Thanks, Hiroshi! This is clear, addition of a new track once a new stable revision appears (2.6) is consistent with the intended use of tracks.

This is a key point which I think furthers the justification for these tracks.

I’m +1 on granting the Ruby tracks.

I’ll create them in a few days once the usual waiting period has elapsed, to allow time for other reviewers to chime in if desired.

Thanks in advance for your patience.

  • Daniel
1 Like
7

These seem to fit the intended patterns for track usage, +1.

8

I am +1 on these tracks - I assume the “2,3” is a typo though, and should be “2.3”

9

We could waive the waiting in this case that is very vanilla and to facilitate the in-person flow. With my architect hat on.

10

Based on @pedronis’s waiver of the waiting period I was able to create the tracks at this time.

Tracks 2.3, 2.4 and 2.5 are ready for Ruby.

Enjoy!

1 Like
11

I’d still have liked to see a photo with that hat though …

12

Hi, all. I did put 2.3, 2.4 tracks. I confirm to work with snap switch and snap refresh commands.

Thanks!

1 Like