ddialliance / ddimodel

Model for DDI Lifecycle
Other
14 stars 6 forks source link

Master branch - management #34

Open spuddybike opened 8 months ago

spuddybike commented 8 months ago

Can we prevent users from forking the master branch, ie only allow them to do so from a develop branch?

jeremyiverson commented 8 months ago

This is not possible as far as I know. Somebody could always clone any branch and switch the remotes, if nothing else. What would the goal of this be?

wlthomas commented 8 months ago

I belive the goal is to maintain a stable "stamped" version as well as have a development master. We achieved this with published versions through the use of a publication repository plus TC managed development version. What we lack here is the repository of released for review versions of 4.0 Beta with a note or link to the revision number of the development version. I think perhaps the easiest means of addressing this is through the creation of a repository of revie versions. It would be useful in this case as there is no published version, but also for other products that go through multiplt reviews.

On Mon, Mar 4, 2024, 13:22 Jeremy @.***> wrote:

This is not possible as far as I know. Somebody could always clone any branch and switch the remotes, if nothing else. What would the goal of this be?

— Reply to this email directly, view it on GitHub https://github.com/ddialliance/ddimodel/issues/34#issuecomment-1977296396, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJT47KVVVFDQAWRHOPHR63YWTCY3AVCNFSM6AAAAABD7725CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXGI4TMMZZGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

DanSmith commented 8 months ago

This is accomplished using tags and the releases.

https://github.com/ddialliance/ddimodel/releases

wlthomas commented 8 months ago

A governance thing. There is a management process of this is through a managed pull request. Only done by pull request requiring administrative override of protection. Review ownership and levels of access. Members of TC and teams that have permissions for individual repositories. Get this written up on how the roles and permissions are managed.