New package for inclusion - alanning:roles

StorytellerCZ commented 4 years ago

Package/project name & description

alanning:roles is the recommended package when it comes to roles.

Links

Current status of the project

[x] Abandoned

Reasoning

Alanning's roles is the recommended package for managing roles in Meteor. Even though major work on version 2 has been done, the package has been abandoned even though there are PRs.

@mitar Any news about this package and what can be done to get v2?

mitar commented 4 years ago

Background: see discussion here: https://github.com/alanning/meteor-roles/issues/270#issuecomment-533396511

In fact there is more development here. I think we should (if @alanning agrees):

Move roles to this repository.
Release v2 with my changes.
Make v3 with what @SimonSimCity made.

StorytellerCZ commented 4 years ago

@mitar All for this plan.

alanning commented 4 years ago

Sounds good to me. I'll update the readme on the alanning/meteor-roles repo to link here once this is ready.

(Although I personally don't consider roles v1 abandoned I haven't done a good job of communicating current status. What's the proper term for security fixes only?)

coagmano commented 4 years ago

What's the proper term for security fixes only?

Long Term Support / LTS?

StorytellerCZ commented 4 years ago

Repo status seems pretty good, but in this case it is missing the LTS tag.

mitar commented 4 years ago

@alanning Just to be clear, I am proposing that:

We move the whole repository under this organization.
We can keep both v1, v2, and v3 branches maintained (probably v3 would be the only one getting feature updates, but we could keep v1 and v2 with security/compatibility updates).
We would be publishing them under the same Meteor package name.

If you agree with that, could you: add me as an owner to the repository, and add communitypackages as maintainer of Meteor package:

meteor admin maintainers alanning:roles --add communitypackages`

alanning commented 4 years ago

@mitar OK, sounds good.

Add maintainer

$ meteor admin maintainers alanning:roles --add communitypackages
Adding a maintainer to alanning:roles...

The maintainers for alanning:roles are:
alanning
mitar
communitypackages

Repo ownership I think github repos can only have one "owner". You are already a "Collaborator" in github for alanning/meteor-roles; is that sufficient? Perhaps I should use the "Transfer ownership" option to move the repo to "Meteor-Community-Packages"?

mitar commented 4 years ago

I think you can make me an Admin which would then allow me to transfer ownership. I think currently I have only Write permissions there. I do not think you can transfer ownership because without having permissions on this organization? But you can try.

alanning commented 4 years ago

Yep, you're correct. Transfer attempt fails with, "You don’t have the permission to create public repositories on Meteor-Community-Packages".

Personal github repos are a bit different than organization ones so either I'll need to be given "create repo" permissions on the org or I'll need to transfer ownership of the repo to you first and then you can transfer to the org.

In order for me to transfer the repo over to you, you will first need to delete your existing mitar/meteor-roles repo.

mitar commented 4 years ago

In order for me to transfer the repo over to you, you will first need to delete your existing mitar/meteor-roles repo.

Done.

copleykj commented 4 years ago

@alanning If you wanted, we'd be more than happy to have you as a member of this org as well

alanning commented 4 years ago

@copleykj Thank you for the invite. Yes, that sounds good. Will get ownership transferred over and read through the org docs.

StorytellerCZ commented 4 years ago

Created a group for the project.

alanning commented 4 years ago

Repo transferred!

mitar commented 4 years ago

Awesome. I suggest that we make the current master branch into v1.0 branch. And then then @SimonSimCity pushes his stuff into master branch as 3.0.

mitar commented 4 years ago

I added @SimonSimCity to the team of maintainers for the repo.

mitar commented 4 years ago

TODO: We have also to create a Meteor org of maintainers of the package.

SimonSimCity commented 4 years ago

@mitar @alanning Thanks for the work so far 👍

I'd propose that we also merge the current v2.0 branch into master and tag it as 2.0. I'll also take a look at the issues and see how we should proceed with them. Most of them will just be asked to move up to a newer version. Should we also leave some "open space" for bugfix versions or will everybody simply have to update to 3.0?

mitar commented 4 years ago

I'd propose that we also merge the current v2.0 branch into master and tag it as 2.0.

So then we first merge v2.0 in to master, and then merge v3.0 into master? I could be OK with that, if you built v3.0 out of v2.0?

I would not use tags in this particular case though, because it seems @alanning would prefer if all versions are maintained.

Should we also leave some "open space" for bugfix versions or will everybody simply have to update to 3.0?

I think if they are just bugfixes (even security ones) we should do them. If they are feature requests, we should suggest to move to 3.0.

SimonSimCity commented 4 years ago

My version (v3) is a modification on top of the v2 branch, yes.

Ok, so how to we realize this when all are merged into master? I originally thought about an approach like gitflow, but I have no idea how we could then realize the work of maintaining all old versions.

Another approach of mine is that we merge everything into master (like gitflow) and if v1 needs a bugfix, we create a separate v1 branch (gitflow calls this a hotfix-release branch) which will never be merged back. It will flow "on it's own" and some of the commits there might then get a tag if they're released as version 1.1 - which is the major difference to it. Is this an approach everyone could live with? All this requires that Atmosphere allows us to release a v1.1 after v2 has been uploaded - I've never tried it.

SimonSimCity commented 4 years ago

Another approach would be the one I've seen in TYPO3. They had the normal development done in master and everytime they were ready to release, they created a branch from which the release was following off from. Every change done for a release was then merged back into master where also the development was.

How does that sound? It's a completely different model but allows for easily maintaining multiple versions.

sebakerckhof commented 4 years ago

All this requires that Atmosphere allows us to release a v1.1 after v2 has been uploaded - I've never tried it.

Yep this works.

StorytellerCZ commented 4 years ago

Since the repo has been transferred and everything set, I'm closing this issue. The discussion I think should continue in the repo with actual PRs.

mitar commented 4 years ago

Started https://github.com/Meteor-Community-Packages/meteor-roles/issues/283.

Meteor-Community-Packages / organization