You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#95 was a significant re-write. I understand that people want to do more work before a "proper" 1.0 release, but it'd be nice to have a rubygems release of current master that we can point at instead of pointing at the git repository. Maybe 0.10.0 or 1.0.0-alpha.1 (ie a prerelease version) or something?
For context, we have been using the gocardless fork for a while and in alphagov/verify-frontend#697 we switched to the official master branch.
Whoa, exciting and slightly scary to see people using our fork!
I'm a little hesitant on this one. Cutting a new version is a signal for people to update to this code, and I know I'm going to break it in the next few weeks. Tools like Dependabot mean people will be notified to the upgrade.
I realise we're still on 0.x, which is full YOLO according to SemVer, but I don't want to cause people a bunch of pain now and then a bunch of new pain when I go breaking things and release 0.11.0. The breakage will be smaller than what we did between the last release and current master, but it will definitely be there.
This sounds like a use case for a prerelease gem which is a gem with a letter in its version number. Rubygems won't install these gems unless you specifically ask it to with the --pre parameter.
This is also semver-compatible. So possible options here are 0.10.0-alpha.1 or 1.0.0-alpha.1 (or whatever letter/numbering scheme you want to use).
I think it's worth getting feedback from motivated users and cutting prereleases that they can use and give feedback on. Motivated users will understand that things are in flux and could change. On the flip side, I completely understand your point about not breaking things all the time in the regular release process.
That said, I still have the option of using git dependencies, so it's not an absolute must-have for me.
0.10.0-alpha.1 sounds about right as an indication of API stability right now. Since we've only just taken over as maintainers, this would be a useful test of our release process too.
I'm happy to release 0.10.0-alpha.1 from the merge commit created by #95, and cut more alpha releases as we hit significant points in our efforts towards a more stable release.
Can't promise I'll get to it today, but will aim to do it this week!
I'm going to move GoCardless over to it as well. From now on we'll use releases from this repo unless we're trying a specific change out in production.
Activity
Sinjo commentedon Apr 30, 2019
Whoa, exciting and slightly scary to see people using our fork!
I'm a little hesitant on this one. Cutting a new version is a signal for people to update to this code, and I know I'm going to break it in the next few weeks. Tools like Dependabot mean people will be notified to the upgrade.
I realise we're still on 0.x, which is full YOLO according to SemVer, but I don't want to cause people a bunch of pain now and then a bunch of new pain when I go breaking things and release 0.11.0. The breakage will be smaller than what we did between the last release and current master, but it will definitely be there.
Thoughts?
philandstuff commentedon May 1, 2019
This sounds like a use case for a prerelease gem which is a gem with a letter in its version number. Rubygems won't install these gems unless you specifically ask it to with the
--preparameter.This is also semver-compatible. So possible options here are
0.10.0-alpha.1or1.0.0-alpha.1(or whatever letter/numbering scheme you want to use).I think it's worth getting feedback from motivated users and cutting prereleases that they can use and give feedback on. Motivated users will understand that things are in flux and could change. On the flip side, I completely understand your point about not breaking things all the time in the regular release process.
That said, I still have the option of using git dependencies, so it's not an absolute must-have for me.
Sinjo commentedon May 7, 2019
0.10.0-alpha.1sounds about right as an indication of API stability right now. Since we've only just taken over as maintainers, this would be a useful test of our release process too.I'm happy to release
0.10.0-alpha.1from the merge commit created by #95, and cut more alpha releases as we hit significant points in our efforts towards a more stable release.Can't promise I'll get to it today, but will aim to do it this week!
Sinjo commentedon May 23, 2019
Just pushed this to RubyGems.
philandstuff commentedon May 23, 2019
Thanks! We've raised alphagov/verify-frontend#703 to use it 😁
Sinjo commentedon May 23, 2019
No worries! Sorry it took so long.
I'm going to move GoCardless over to it as well. From now on we'll use releases from this repo unless we're trying a specific change out in production.