[Xerte-dev] Re: GitHub and Workflows

Mon Sep 9 09:21:50 BST 2013

That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis...

-----Original Message-----
From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John
Sent: 07 September 2013 12:07
To: For Xerte technical developers
Subject: [Xerte-dev] Re: GitHub and Workflows

Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch...

We should document this process somewhere and refer to in until it is instilled in our brains.

Regards,

John Smith | Learning Technologist
Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________
From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl]
Sent: 07 September 2013 11:51
To: For Xerte technical developers
Subject: [Xerte-dev] Re: GitHub and Workflows

In that, I think, git will help us more than SVN was.

For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/):

Whenever we identify a bug that needs to go in the latest release:
1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one.

Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one.

The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate.

The only drawback so far is that if a release has so many new features that not anyone is able to move to the new release, we might need to maintain a previous release for some time (think of the need to go to for example php 5.4, or something similar)

We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary).

So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying!

[cid:part1.06000105.04050501 at tor.nl]

Op 7-9-2013 10:02, Smith, John schreef:

Morning all,

The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes...

Not really sure how the releases and hotfixes should work though...

I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over...

Regards,

John Smith | Learning Technologist
Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________
From: xerte-dev-bounces at lists.nottingham.ac.uk<mailto:xerte-dev-bounces at lists.nottingham.ac.uk> [xerte-dev-bounces at lists.nottingham.ac.uk<mailto:xerte-dev-bounces at lists.nottingham.ac.uk>] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk<mailto:Julian.Tenney at nottingham.ac.uk>]
Sent: 06 September 2013 14:37
To: For Xerte technical developers
Subject: [Xerte-dev] Re: GitHub and Workflows

I asked him to commit to 'develop'.

I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...?

________________________________
From: xerte-dev-bounces at lists.nottingham.ac.uk<mailto:xerte-dev-bounces at lists.nottingham.ac.uk> [xerte-dev-bounces at lists.nottingham.ac.uk<mailto:xerte-dev-bounces at lists.nottingham.ac.uk>] On Behalf Of Tom Reijnders [reijnders at tor.nl<mailto:reijnders at tor.nl>]
Sent: 06 September 2013 14:14
To: For Xerte technical developers
Subject: [Xerte-dev] Re: GitHub and Workflows

Hi,

I am in the process of modifying the build scripts to use github in stead of svn.

And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below:

1. Will we do hotfixes on released branches, i.e. on master and 2.0?
2. What shall we put up on the community website? What is the equivalent  to the svn trunk. master or develop, i.e. what is the basis for 'unstable'?

Regards,

Tom

Op 5-9-2013 15:39, Julian Tenney schreef:
Hi,

I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example).

I like it for several reasons:

-          The 'master' branch is always production quality released code

-          Small developments (trivial) can be undertaken directly in 'develop'

-          Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete...

-          ...testing of develop can then be undertaken before we make a new release number.

See the information for more details. Does this seem sensible and agreeable to everyone?

There are two other things I'd like us to work towards, again subject to some discussion between us:

Using Tickets for Issues and New Features:

-          Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these;

-          Using those tickets as a way of grouping work into sprints towards a new release;

-          Could be trac, could be github, open to suggestions;

A better means of testing the software rather than the hit and hope method we currently employ:

-          Open to suggestions here?

-          Probably starts with a list of manual tests to work through?

-          Possibly includes automation (Selenium?)

-          UnitTesting probably a very long term goal, might not even be possible?

So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views...

Thanks,

Julian

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

_______________________________________________
Xerte-dev mailing list
Xerte-dev at lists.nottingham.ac.uk<mailto:Xerte-dev at lists.nottingham.ac.uk><mailto:Xerte-dev at lists.nottingham.ac.uk><mailto:Xerte-dev at lists.nottingham.ac.uk>
http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev

--
--

Tom Reijnders
TOR Informatica
Chopinlaan 27
5242HM Rosmalen
Tel: 073 5226191
Fax: 073 5226196

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Glasgow Caledonian University is a registered Scottish charity, number SC021474

Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009.
http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html

Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners.
http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html

_______________________________________________
Xerte-dev mailing list
Xerte-dev at lists.nottingham.ac.uk<mailto:Xerte-dev at lists.nottingham.ac.uk>
http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev
This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

--
--

Tom Reijnders
TOR Informatica
Chopinlaan 27
5242HM Rosmalen
Tel: 073 5226191
Fax: 073 5226196

Glasgow Caledonian University is a registered Scottish charity, number SC021474

Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009.
http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html

Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners.
http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html

_______________________________________________
Xerte-dev mailing list
Xerte-dev at lists.nottingham.ac.uk
http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev