hehopmajieh
commented
5 years ago Hi, rel3 will be merged into master, when I am sure that changes made in this branch working well.
~Best
On Tue, 5 Mar 2019, 20:36 JC Staudt, notifications@github.com wrote:
Assigned #37 https://github.com/OLIMEX/DIY-LAPTOP/issues/37 to @hehopmajieh https://github.com/hehopmajieh.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/OLIMEX/DIY-LAPTOP/issues/37#event-2181849627, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrmZUDUrVpq8EnnKXBd8n4Veuq86ybtks5vTrkrgaJpZM4bfPk- .
Can we please discuss the use of release branches versus release tags (i.e. rel3 branch vs tagging a version number onto the master branch)? One thing I like about release tags rather than release branches is that it is much more difficult to mess them up (i.e. you can accidentally append a commit onto the branch after it's been released). Release tags point to a specific commit and make it easier to disseminate.
It makes perfect sense to begin developing toward a rev3 release but, stable and merged rev1/rev2/rev3/etc commits are often marked as tags in master; official releases are then released off of master to ease the task of external users downloading the package appropriately. Deprecating master to progress further on a rev3 branch would (I believe) be confusing as the goal of a branch is to break off until development has matured, to eventually be merged back into the master branch. Contributors could also be left committing to a stale branch, not knowing that another had been made active. From my understanding, moving the primary branch from master to rev3 would deviate from common git practices.