[Gmod-tripal-devel] Committing to the Drupal.org repository

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Gmod-tripal-devel] Committing to the Drupal.org repository

Lacey-Anne Sanderson
I see that a 6.x-0.4-dev branch has been added to the Drupal.org Tripal repository. I just wanted to clarify the workflow for making changes to Tripal so that we're all on the same page.

Workflow:
1. Checkout devel branch
git pull origin
git checkout 6.x-0.4.dev
2. Make changes
3. Do testing (currently manual testing)
4. Repeat steps 2 & 3 until confident change hasn't broken related parts in Tripal
5. Commit changes to devel branch
git status
git add .
git commit -am "<Modulename>: <Change made>"
-if commit is related to a single module, the commit message should be "Modulename: change made"

At what point should the devel branch be merged with master?
Also, when we say master what do we mean? ie: should this always be the current release?

I often need the newest features of Tripal on my production site -if people could not commit to devel until they're relatively sure it hasn't broken anything that would allow me to use the devel branch directly.

~Lacey

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan


------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-tripal-devel] Committing to the Drupal.org repository

Stephen Ficklin-2
Hi Lacey,

I believe Alex created the 6.x-0.4-dev branch so as not to alter the current state of the master branch which has our code as it came from the SVN repository.  He's been working with themeing a bit.  

So here is my proposal.  I think we should have only a single branch for active group development.  Any work we all do as a group gets committed to this primary development branch.  Each time we issue a release we create a new branch for that release (e.g. Tripal-v6.x-0.4) and put the code in there.   But this release branch doesn't get created until we are preparing to make the release.  We can then use those release branches in the future for making bug fixes and minor releases on those versions.

Then, if we do branch for any other reason, it should only be for exploratory things, like Drupal 7, etc.  Or if someone individually wants to create a branch for some other non-democratically approved changes then perhaps those branches should be prefixed with the person's Drupal user name.  

This way, we only have one active development branch and we maintain strict naming for releases.

So, I don't know the differences between the 6.x-0.4-dev branch that Alex created and the master branch, other than perhaps the theming work that has been done.  Alex is out sick today so we'll have to wait to ask him.  If there are no other differences then I suggest we just keep the "master" branch as our main development branch.

Stephen


On 12/13/2011 1:47 PM, Lacey-Anne Sanderson wrote:
I see that a 6.x-0.4-dev branch has been added to the Drupal.org Tripal repository. I just wanted to clarify the workflow for making changes to Tripal so that we're all on the same page.

Workflow:
1. Checkout devel branch
git pull origin
git checkout 6.x-0.4.dev
2. Make changes
3. Do testing (currently manual testing)
4. Repeat steps 2 & 3 until confident change hasn't broken related parts in Tripal
5. Commit changes to devel branch
git status
git add .
git commit -am "<Modulename>: <Change made>"
-if commit is related to a single module, the commit message should be "Modulename: change made"

At what point should the devel branch be merged with master?
Also, when we say master what do we mean? ie: should this always be the current release?

I often need the newest features of Tripal on my production site -if people could not commit to devel until they're relatively sure it hasn't broken anything that would allow me to use the devel branch directly.

~Lacey

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan



------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-tripal-devel] Committing to the Drupal.org repository

Lacey-Anne Sanderson
Having a version-dev branch is a drupal standard so I think that should be our main development branch. I like the idea of creating branches for each of the releases. 

I see the likelihood of problems in the future with the master branch -people could commit to it by accident and then it be out of sync with both the release and the development branch... Can we use symbolic-ref to create the dev branches so they actually point to master. Then master is our main development branch and release branches are completely separate?

Then our workflow would be to make all our development changes to master and if people checkout the 6.x-0.4-dev branch, they're actually checking out master... Whats the normal workflow for Drupal projects?

~Lacey

PS> I committed a fix for library sync'ing to the 6.x-0.4-dev branch

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan

On 2011-12-13, at 1:13 PM, Stephen Ficklin wrote:

Hi Lacey,

I believe Alex created the 6.x-0.4-dev branch so as not to alter the current state of the master branch which has our code as it came from the SVN repository.  He's been working with themeing a bit.  

So here is my proposal.  I think we should have only a single branch for active group development.  Any work we all do as a group gets committed to this primary development branch.  Each time we issue a release we create a new branch for that release (e.g. Tripal-v6.x-0.4) and put the code in there.   But this release branch doesn't get created until we are preparing to make the release.  We can then use those release branches in the future for making bug fixes and minor releases on those versions.

Then, if we do branch for any other reason, it should only be for exploratory things, like Drupal 7, etc.  Or if someone individually wants to create a branch for some other non-democratically approved changes then perhaps those branches should be prefixed with the person's Drupal user name.  

This way, we only have one active development branch and we maintain strict naming for releases.

So, I don't know the differences between the 6.x-0.4-dev branch that Alex created and the master branch, other than perhaps the theming work that has been done.  Alex is out sick today so we'll have to wait to ask him.  If there are no other differences then I suggest we just keep the "master" branch as our main development branch.

Stephen


On 12/13/2011 1:47 PM, Lacey-Anne Sanderson wrote:
I see that a 6.x-0.4-dev branch has been added to the Drupal.org Tripal repository. I just wanted to clarify the workflow for making changes to Tripal so that we're all on the same page.

Workflow:
1. Checkout devel branch
git pull origin
git checkout 6.x-0.4.dev
2. Make changes
3. Do testing (currently manual testing)
4. Repeat steps 2 & 3 until confident change hasn't broken related parts in Tripal
5. Commit changes to devel branch
git status
git add .
git commit -am "<Modulename>: <Change made>"
-if commit is related to a single module, the commit message should be "Modulename: change made"

At what point should the devel branch be merged with master?
Also, when we say master what do we mean? ie: should this always be the current release?

I often need the newest features of Tripal on my production site -if people could not commit to devel until they're relatively sure it hasn't broken anything that would allow me to use the devel branch directly.

~Lacey

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan




------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-tripal-devel] Committing to the Drupal.org repository

Oleksiy Golovin
Hello All,
When working with drupal.org's git repositories, we need to adhere to their practices:
 1. "master" branch can be the branch that we are updating the most or it can be empty. Master branch is a placeholder of sorts for a project's git repository.
 2. Releases are tags on branches. See http://drupal.org/node/1068944 for details.

When using git, I think we should try to use a practice similar to the one described in this article: http://nvie.com/posts/a-successful-git-branching-model/ , the tl:dr version is summed up in that first picture: http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png .

Branch/Tag naming convention ( does not apply to master) should be like this:
6.x-0.4-dev;  first number is version of the dot release; second number after dot is the sub-releases or if it is meant as a dev only branch .x can be used; second set of numbers is our project version; the last string should be dev for development only, rc# - release candidate followed by a number, alpha/beta etc.

This is what should happen for regular dev:
Once you have cloned the git repository and are ready to start work on some feature( or bug fix):
1. git checkout 6.x-0.4-dev (the branch that you are going to use as starting point for your feature/bug fix.)
2. git checkout -b newbranchname (newbranchname can be 6.x-0.4-dev-featurename)
3. do your work here and 
    i. git add . (or git add specificfilepath)
    ii. git commit -am'commit message'  (the -a is for commiting all that's been commited in git add)
4. test to make sure your code does not break.
5. if your code works correctly without seeming to break anything right off the bat, commit to the dev branch that you based your work on (and you are done). If it is breaking and you need help with it, you should commit all changes to the branch you are working on, and "git push origin newbranchname". At which point you either need to set up your local git repo to track that branch or just do "git pull origin newbranchname" to pull other peoples commits to it.
6. Once the code is fairly stable, then, you merge it back into the dev branch you based your working branch on.

When we are about to do a release, the dev branch/master or even a separate release branch, must be tagged and the following procedure must be used: http://drupal.org/node/1068944.

Notes similar to the git strategy I've linked above, http://drupal.org/files/maintain-release-handout.pdf .
I'm also attaching my brief conversation from #drupal-contribute:

<alexgl> when putting release versions of projects. Does one use branches for those or tags on d.o?
<berdir> alexgl: branch for dev snapshots and then tags on them for fixed releases
<xjm> alexgl: for a dev release, you use the branch.  for a regular release, add a tag to the branch.
<xjm> alexgl: in both cases you need to associate a release node with it
<alexgl> xjm, berdir and do those tags get picked up automatically? also what do you use master branch for?
<alexgl> xjm, the release node, how does that work?
<xjm> alexgl: you will need to push the tags.  see the git instructions tab.
<xjm> alexgl: you can leave the master branch empty.
<xjm> release?
<Druplicon>  Releases are now based on Git tags. See http://drupal.org/node/1068944. See also http://drupal.org/files/maintain-release-handout.pdf
<xjm> alexgl: ^ see those instructions
<alexgl> xjm, thanks

Please let me know what you think and/or your questions,

Alex





On Tue, Dec 13, 2011 at 11:57 AM, Lacey-Anne Sanderson <[hidden email]> wrote:
Having a version-dev branch is a drupal standard so I think that should be our main development branch. I like the idea of creating branches for each of the releases. 

I see the likelihood of problems in the future with the master branch -people could commit to it by accident and then it be out of sync with both the release and the development branch... Can we use symbolic-ref to create the dev branches so they actually point to master. Then master is our main development branch and release branches are completely separate?

Then our workflow would be to make all our development changes to master and if people checkout the 6.x-0.4-dev branch, they're actually checking out master... Whats the normal workflow for Drupal projects?

~Lacey

PS> I committed a fix for library sync'ing to the 6.x-0.4-dev branch

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: <a href="tel:%28306%29%20966-2430" value="+13069662430" target="_blank">(306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan

On 2011-12-13, at 1:13 PM, Stephen Ficklin wrote:

Hi Lacey,

I believe Alex created the 6.x-0.4-dev branch so as not to alter the current state of the master branch which has our code as it came from the SVN repository.  He's been working with themeing a bit.  

So here is my proposal.  I think we should have only a single branch for active group development.  Any work we all do as a group gets committed to this primary development branch.  Each time we issue a release we create a new branch for that release (e.g. Tripal-v6.x-0.4) and put the code in there.   But this release branch doesn't get created until we are preparing to make the release.  We can then use those release branches in the future for making bug fixes and minor releases on those versions.

Then, if we do branch for any other reason, it should only be for exploratory things, like Drupal 7, etc.  Or if someone individually wants to create a branch for some other non-democratically approved changes then perhaps those branches should be prefixed with the person's Drupal user name.  

This way, we only have one active development branch and we maintain strict naming for releases.

So, I don't know the differences between the 6.x-0.4-dev branch that Alex created and the master branch, other than perhaps the theming work that has been done.  Alex is out sick today so we'll have to wait to ask him.  If there are no other differences then I suggest we just keep the "master" branch as our main development branch.

Stephen


On 12/13/2011 1:47 PM, Lacey-Anne Sanderson wrote:
I see that a 6.x-0.4-dev branch has been added to the Drupal.org Tripal repository. I just wanted to clarify the workflow for making changes to Tripal so that we're all on the same page.

Workflow:
1. Checkout devel branch
git pull origin
git checkout 6.x-0.4.dev
2. Make changes
3. Do testing (currently manual testing)
4. Repeat steps 2 & 3 until confident change hasn't broken related parts in Tripal
5. Commit changes to devel branch
git status
git add .
git commit -am "<Modulename>: <Change made>"
-if commit is related to a single module, the commit message should be "Modulename: change made"

At what point should the devel branch be merged with master?
Also, when we say master what do we mean? ie: should this always be the current release?

I often need the newest features of Tripal on my production site -if people could not commit to devel until they're relatively sure it hasn't broken anything that would allow me to use the devel branch directly.

~Lacey

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: <a href="tel:%28306%29%20966-2430" value="+13069662430" target="_blank">(306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan





------------------------------------------------------------------------------
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-tripal-devel] Committing to the Drupal.org repository

Lacey-Anne Sanderson
Okay,

I think having a development and a master branch will just be asking for trouble. Since we're coming from an SVN background it's more intuitive to do our main development to the master. The branching for releases is the same as what we did in svn except with the addition of adding a tag. The main difference is creating our own branches for new features which we then merge back into master once finished and fully tested.

Summary:
- Master branch should be for main development
- Release branches should be named 6.x-0.4-dev and only be created when a release is ready (created by Stephen only)
- first commit on release branch is to change version number
- release branch is tagged 6.x-0.4 (tagged by Stephen)
- only bug fixes made to release branch
- any branches other then master and release should be the name of the feature and not have a version number in it (ie: view_integration)
- no commits are made to master until code has been thoroughly tested
(See Diagram attached)

Following this, the 6.x-0.4-dev branch should not have been created yet...

~Lacey


------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan

On 2011-12-14, at 11:45 AM, Oleksiy Golovin wrote:

Hello All,
When working with drupal.org's git repositories, we need to adhere to their practices:
 1. "master" branch can be the branch that we are updating the most or it can be empty. Master branch is a placeholder of sorts for a project's git repository.
 2. Releases are tags on branches. See http://drupal.org/node/1068944 for details.

When using git, I think we should try to use a practice similar to the one described in this article: http://nvie.com/posts/a-successful-git-branching-model/ , the tl:dr version is summed up in that first picture: http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png .

Branch/Tag naming convention ( does not apply to master) should be like this:
6.x-0.4-dev;  first number is version of the dot release; second number after dot is the sub-releases or if it is meant as a dev only branch .x can be used; second set of numbers is our project version; the last string should be dev for development only, rc# - release candidate followed by a number, alpha/beta etc.

This is what should happen for regular dev:
Once you have cloned the git repository and are ready to start work on some feature( or bug fix):
1. git checkout 6.x-0.4-dev (the branch that you are going to use as starting point for your feature/bug fix.)
2. git checkout -b newbranchname (newbranchname can be 6.x-0.4-dev-featurename)
3. do your work here and 
    i. git add . (or git add specificfilepath)
    ii. git commit -am'commit message'  (the -a is for commiting all that's been commited in git add)
4. test to make sure your code does not break.
5. if your code works correctly without seeming to break anything right off the bat, commit to the dev branch that you based your work on (and you are done). If it is breaking and you need help with it, you should commit all changes to the branch you are working on, and "git push origin newbranchname". At which point you either need to set up your local git repo to track that branch or just do "git pull origin newbranchname" to pull other peoples commits to it.
6. Once the code is fairly stable, then, you merge it back into the dev branch you based your working branch on.

When we are about to do a release, the dev branch/master or even a separate release branch, must be tagged and the following procedure must be used: http://drupal.org/node/1068944.

Notes similar to the git strategy I've linked above, http://drupal.org/files/maintain-release-handout.pdf .
I'm also attaching my brief conversation from #drupal-contribute:

<alexgl> when putting release versions of projects. Does one use branches for those or tags on d.o?
<berdir> alexgl: branch for dev snapshots and then tags on them for fixed releases
<xjm> alexgl: for a dev release, you use the branch.  for a regular release, add a tag to the branch.
<xjm> alexgl: in both cases you need to associate a release node with it
<alexgl> xjm, berdir and do those tags get picked up automatically? also what do you use master branch for?
<alexgl> xjm, the release node, how does that work?
<xjm> alexgl: you will need to push the tags.  see the git instructions tab.
<xjm> alexgl: you can leave the master branch empty.
<xjm> release?
<Druplicon>  Releases are now based on Git tags. See http://drupal.org/node/1068944. See also http://drupal.org/files/maintain-release-handout.pdf
<xjm> alexgl: ^ see those instructions
<alexgl> xjm, thanks

Please let me know what you think and/or your questions,

Alex





On Tue, Dec 13, 2011 at 11:57 AM, Lacey-Anne Sanderson <[hidden email]> wrote:
Having a version-dev branch is a drupal standard so I think that should be our main development branch. I like the idea of creating branches for each of the releases. 

I see the likelihood of problems in the future with the master branch -people could commit to it by accident and then it be out of sync with both the release and the development branch... Can we use symbolic-ref to create the dev branches so they actually point to master. Then master is our main development branch and release branches are completely separate?

Then our workflow would be to make all our development changes to master and if people checkout the 6.x-0.4-dev branch, they're actually checking out master... Whats the normal workflow for Drupal projects?

~Lacey

PS> I committed a fix for library sync'ing to the 6.x-0.4-dev branch

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: <a href="tel:%28306%29%20966-2430" value="+13069662430" target="_blank">(306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan

On 2011-12-13, at 1:13 PM, Stephen Ficklin wrote:

Hi Lacey,

I believe Alex created the 6.x-0.4-dev branch so as not to alter the current state of the master branch which has our code as it came from the SVN repository.  He's been working with themeing a bit.  

So here is my proposal.  I think we should have only a single branch for active group development.  Any work we all do as a group gets committed to this primary development branch.  Each time we issue a release we create a new branch for that release (e.g. Tripal-v6.x-0.4) and put the code in there.   But this release branch doesn't get created until we are preparing to make the release.  We can then use those release branches in the future for making bug fixes and minor releases on those versions.

Then, if we do branch for any other reason, it should only be for exploratory things, like Drupal 7, etc.  Or if someone individually wants to create a branch for some other non-democratically approved changes then perhaps those branches should be prefixed with the person's Drupal user name.  

This way, we only have one active development branch and we maintain strict naming for releases.

So, I don't know the differences between the 6.x-0.4-dev branch that Alex created and the master branch, other than perhaps the theming work that has been done.  Alex is out sick today so we'll have to wait to ask him.  If there are no other differences then I suggest we just keep the "master" branch as our main development branch.

Stephen


On 12/13/2011 1:47 PM, Lacey-Anne Sanderson wrote:
I see that a 6.x-0.4-dev branch has been added to the Drupal.org Tripal repository. I just wanted to clarify the workflow for making changes to Tripal so that we're all on the same page.

Workflow:
1. Checkout devel branch
git pull origin
git checkout 6.x-0.4.dev
2. Make changes
3. Do testing (currently manual testing)
4. Repeat steps 2 & 3 until confident change hasn't broken related parts in Tripal
5. Commit changes to devel branch
git status
git add .
git commit -am "<Modulename>: <Change made>"
-if commit is related to a single module, the commit message should be "Modulename: change made"

At what point should the devel branch be merged with master?
Also, when we say master what do we mean? ie: should this always be the current release?

I often need the newest features of Tripal on my production site -if people could not commit to devel until they're relatively sure it hasn't broken anything that would allow me to use the devel branch directly.

~Lacey

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: <a href="tel:%28306%29%20966-2430" value="+13069662430" target="_blank">(306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan






------------------------------------------------------------------------------
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel

Tripal_git.pdf (348K) Download Attachment