Hey Glaucia, Great idea! +1
Best, —Alex > On 19. Sep 2023, at 17:15, Gláucia Esppenchutz <[email protected]> wrote: > > Hi everyone, > > I was thinking about using the git-flow model of branching strategy. More > or less having the following branches: > "main" renamed to "release" > "rel/x.x.x" > "cherry-pick" > "develop" > "feat/bug" > Here, we would use the "release" as the current stable state from Wayang. > The "release" would have the same content as the latest "rel/x.x.x" branch. > > About the "rel/x.x.x", the ideal would be to keep track of all versions we > have, and if anyone needs to use an older version, it will be there > (likewise the tag). > The "develop" branch would be where we merge the approved PRs, and it may > not be stable since we are always opening and merging new content. To work > on a new feature, we would ask the developer to create a new > "feature/bugfix" from the "develop" branch and work there. > > After we decided we were ready to make a new release, we would pick the > features and fixes implemented on "develop" and cherry-pick them in a > specific branch called "cherry-pick" (so innovative). After doing some > testing and making sure we are able to compile and meet the Apache guides, > we will proceed to create the "rel/" branch by maven commands. > > Once the "rel/" conforms with Apache approvals, the content would be then > merged into "release" (default branch), so developers who want to use > Wayang have an easy and intuitive way to find the latest and stable version. > > What do you think? :) -- databloom AI, Inc. 3401 N. MIAMI AVE. STE 230 33127 Miami, Florida United States -- Please consider the environment before printing this email -- Disclaimer: The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message.
