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"
<[email protected]>:
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
<[email protected]>:
>
> 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" <[email protected]>:
>
> 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
>
