plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: Usage of GIT (was: [SCALA-API] Scala API branch pushed to gitbox repo)
Date Sun, 24 Dec 2017 12:37:12 GMT
As Justin brought this up in the original SCAPA-API thread, I think we should also discuss
the branching concept.

Right now, we’re developing on “master” … I think this is ok as long as we don’t
have a first release. After that I would suggest moving development to a develop branch and
merge releases to the master branch. This way, whenever someone clones the repo, he’ll be
on the last released state (which should be stable). “Develop” would be the unstable branch
on which all the coding is done.

Whenever we are thinking of a Major or Minor release, we kick of a “[DISCUSS]” thread
on the dev-list and as soon as there’s consensus on initiating a new release and which version
it’s going be, a branch is created “release/{major.minor}” (no bug-fix part) … the
version of develop is incremented to the next minor or major version. In the release branch
is where the build is stabilized prior to cutting the release candidate. No new features should
be merged into this branch. Any fixes from it should be cherry-picked into develop (Don’t
merge as this will also update the versions of all artifacts). Development on “develop”
can continue normally. 

As soon as a release candidate is created, the revision on the release branch is tagged with
that release version and if the RC is released, this tag is merged back to master.

Bug-fix releases are continued on the existing release branch and tagged & merged accordingly.

I think there shouldn’t be a requirement to implement everything in feature-branches, however
if you want to start working on something and need to share with the others working on that
feature too, I would suggest using a feature branch. Also, if you are working on something
major that has to be discussed with the rest of the team. I wouldn’t like to see any mails
of the type: “I just committed something that will break XYZ, but I’ll fix that tomorrow”
… we’ve had that in other projects and it usually results in great frustration with the
rest of the team. So, whenever you commit something it should not break anything, if it does
and you know it, please create a feature branch. 

Regarding the naming, we should agree on a naming convention so we can setup the Jenkins Multibranch
Pipeline plugin to find them. So I would suggest “feature/{some name}” or “feature/{JIRA-ID}”.

This is just my opinion and your opinion is worth just as much, so please comment on these
suggestions if you agree or don’t … if you don’t agree it’s always good to add some
reasoning to why you don’t agree and what you would do instead.

So now all I can do is wish you all a very merry Christmas … I’ll save the happy new year
for another email ;-)

CU all,
      Chris


Am 22.12.17, 17:27 schrieb "Mark Keinhörster" <mark.keinhoerster@codecentric.de>:

    Hi Chris,
    I agree with you. I also prefer merging for ease of use and simplicity.
    
    Thanks,
    Mark
    
    > Am 22.12.2017 um 12:44 schrieb Christofer Dutz <christofer.dutz@c-ware.de>:
    > 
    > Hi Benedict,
    > 
    > thanks for providing your work … I know there was at least one further person planning
on working on the SCALA api.
    > 
    > In general, I usually only rebase if I haven’t pushed anything. 
    > 
    > I think we should never break someone elses work just for the sake of a cleaner commit
graph. As we never quite know if some potentially new committer has started to work on something,
I think we shouldn’t do that.
    > 
    > So, my opinion would be to merge. But I think this would be a good topic to start
discussing here. Especially the new born Apaches are encouraged to join the discussion
    > 
    > Chris
    > 
    > 
    > Am 22.12.17, 10:20 schrieb "Benedikt Ritter" <britter@apache.org>:
    > 
    >    Hi all,
    > 
    >    I’ve just pushed the work I’ve started a few weeks ago on the Scala API to
the gitbox repo. The branch is called PLC4X-12 (the name of the lira issue). The branch is
currently outdated, because we introduced some changes to the Java API after started my work.
I never got around to bringing the branch up to date with current master. But maybe somebody
wants to continue working on the Scala API, so there it is :o)
    >    I don’t think we have agreed on how to work with git yet. Do we want to rebase
the branch thereby potentially breaking peoples working copies or do we simply merge master
to the PLC4X-12 branch?
    > 
    >    Cheers,
    >    Benedikt
    > 
    
    

Mime
View raw message