Do we have a maintainer ?

[mathieujobin]

@ofedoren is there someone else than you reviewing PR ?

we would like to get a few things forward, so that tests runs again.
and we can support rails 7. and remove unnecessary dependendies.

if you need help, you can add me on both github and rubygems, and I will get the few priorities items going.
my client is using this gem and we would love NOT to fork it ..

I maintain many legacy gem, please see my rubygems profile

https://rubygems.org/profiles/mathieu

[sasharevzin]

@mathieujobin honestly, @ofedoren never replied to my comments nor others once. I would vote for creating a new apipie2 gem so we won’t be dependent on them. Thoughts?

[mathieujobin]

He merged a small PR just a week ago... So he should be around...

Renaming the gem is annoying.

This one is in a team already.

I hope they can pass the flame 🔥

[mathieujobin]

@iNecas u around?

[mtparet]

Hello,

I am still an admin of the project so I could help moving forward here. But I do not want to do anything against @iNecas @ofedoren @tstrachota @Pajk so could you try to ask them by others ways (than github, by email for example) what are their intentions here ?

If they are ok or no answers we will need at least 2 maintainers so one can review/approve PR of the other one.

[iNecas]

Hi, I've not been active apipie-rails anymore for some time, neither involved in a project that would be using it. I'm however interested for it in being in good hands. Let's give @ofedoren some time here to respond here before we proceed.

[ofedoren]

@mathieujobin, thanks for the proposition!

As I've already answered here: #734 (comment), there is no active maintainer unless there is something that is needed by the project I'm currently in, thus the things are moving slowly here.

But since there are so many people willing to help, I'm going to proceed with my proposition about having two branches: master and stable. I'm going to release a major 1.0.0 version based on current master branch and at the same time I'll create a new stable branch for minor releases such as 0.5.20+. This way, users could lock their Gemfiles to use apipie-rails >= 1.0.0 for the newest changes or lock it to use < 1.0.0 in case they need the current state of the gem, but with small improvements. If it sounds OK, I'd do that on Wed Mar 2nd, 2022, just so people have time to lock their versions. In terms of maintainers, I'm going to create a new team Apipie - Maintainers with Maintainer rights on the repo with @mathieujobin as an admin for that group in case more people would want to be maintainers.

This should give you more freedom in merging/releasing.

What do you think about this?

[mathieujobin]

@ofedoren I will suggest we merge #740 before creating the stable branch, so that should a PR be opened against the stable branch. the tests will run on Github Actions.

Travis no longer runs the tests.

[ofedoren]

Hi @mathieujobin and all the others,

My apologies, but I need to postpone the planned stuff till Saturday/Sunday at least due to personal issues I need to deal with. Hope you understand.

[mathieujobin]

No worries

This isn't a pressing issue on my end.

[themilkman]

Thanks @ofedoren for your decision! Sound's like a good plan.
One thing not to forget (at least after a while) is to add someone additional to the rubygems group to ensure releases.

I am glad to see progress - just today I got a hand full CVE audit reports of our applications due to active-storage - which is only inside the Gemfile.lock as apipie requires them as dependency. So, I am really happy :)

Thanks also to @mathieujobin for your offer to help!

[mathieujobin]

@ofedoren Hey, I'm not sure if there is anything pending on me? do I need to do something?
what's next?

[mathieujobin]

@ofedoren lets get the ball rolling

I would release current master as 0.5.20 as it contains only a small warning fix, typos and the tests to run
and #716 as 0.6.0 which is ruby 3.x support

[ofedoren]

I know it's been two weeks, I'm just all over the place.

Let's release 0.5.20 today (16.03) as the last stable version. And then release 1.0.0 with the ruby 3.x support?

I'll try to prepare the repo and add you to the places this evening.

[ofedoren]

@mathieujobin, I've added you as a standalone collaborator for this repo (unfortunatelly it appears I cannot modify number of the people in the organization). There now two branches, you might want to use master only for all of the PRs and future releases. Please ping me when we're ready to release 1.0.0 from master, I'll do that (I promise!) or you might want to use Jupyter notebook in rel-eng yourself to make consistent releases.

In case I forgot something, please ping me or better send me an email.

[mathieujobin]

@ofedoren I don't think I will do it the way you want. So maybe you should find someone else to do it how you like.
I probably should have squash merge #716, and I don't have much interest in learning rel-eng

We can redo the merge by reopening a new PR though and force pushing the result onto master...

sorry

[themilkman]

Hello friends, nice to see progress! Thanks.

Just to give my 2 cent:

• Regarding squashing: I don't like that. I prefere merge commits (even if fast forward would) work for the sake of keeping a probably good structured commit history and nevertheless being able to revert the merge by a single commit-revert
• I like the stable/master branch model that's now applied (although personally I prefere git flow with develop/master/feature/release branches)
• Let's see how much progress we get into the master branch now in order to soon get a stable and nice 1.0.0 release :)
• @mathieujobin : maybe I missunderstood either one of you but I didn't see any criticism of @ofedoren regarding you - or that you'd have to use rel-eng or so. Let's keep this rolling :)

In case I may contribute in any way, feel free to ping me - I'll try to find time and do my best.

[ofedoren]

Thanks, @themilkman, I never criticize anyone but myself :)

It was just a suggestion on how to proceed. As I've said, the main branch can be treated in any way, moreover if the active maintainer decides to go with e.g. git flow, I'm totally ok with that. I'm just not so sure about the vision @mathieujobin had. If it was more about reviewing/merging only, that's ok as well, I can find time to do releases biweekly/each week depending on how much was merged.

[mathieujobin]

ok, sorry I wasn't feeling great this morning.

so I guess I could go through the open PR and select a few and release 1.0 with that...
but I kind of prefer doing it pieces by pieces.
this is the reason I proposed to release the ruby 3.x as 0.6.0
it does not have any breaking changes. and it adds on top of the existing.
then I would release a few small PR as 0.6.1, 0.6.2, etc. going into that direction.
1.0 could drop support for older rubies, making 2.6 or 2.7 the minimum...
or it could be significantly different. I just don't feel we have anything on the table right now for ask users to do an explicit upgrade.

I think the question boils down to

if a user has the gem locked as ~> 0.5 can he do bundle update safely?

and right now the answer is Yes !

[mathieujobin]

about rel-eng, I noticed this commit 05c0783 but really, I have no idea what it does...

[themilkman]

For me it sounds reasonable to have "API" compatible, non-breaking minor releases before as semantic versioning suggests.
Folks also may pin ~> 0.5.0 in case they don't feel comfortable anyways.

[ofedoren]

ok, sorry I wasn't feeling great this morning.

Me neither :) No problem.

this is the reason I proposed to release the ruby 3.x as 0.6.0
...
then I would release a few small PR as 0.6.1, 0.6.2, etc. going into that direction.

We still can do that in stable branch. I mean the 0.6.0, 0.6.1, etc. As far as this is stable and there is no breaking changes, no dropping, etc. It'd just require a CP from master branch.

Actually, the reason why I've created stable branch is to have there only cherry-picked commits that don't have any breaking changes or at least were tried out in production already.

@mathieujobin, please feel free to adopt the repo as you see it so there is nothing blocking you. Or if there is something I should do, please feel free to tell as well. In worst case I'll adopt and be responsible, no problem :)

P.S. rel-eng is just an automated cheat sheet to make a release. It's not a mandatory thing to use. Honestly, I made it mostly for myself to not forget anything, plus it has a useful parser for release notes. But if you don't feel it's useful, you can ignore that, sure.

[mathieujobin]

sounds good to me ! I'm aiming at keep master==stable for as long as possible.