New automated build branch?
- mwm
-
Topic Author
- Offline
Less
More
01 May 2016 15:57 #47552
by mwm
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
New automated build branch? was created by mwm
Now that 5.0 is out, I'd like to propose a second branch of automated builds. But I believe PB will need to set this up.
One of the issues we saw was people going to the nightly just to get bug fixes or protocols that weren't available in 4.0.1. I think many of those people would have been better off with a build based on the release + bug fixes and protocols. So could we get an automated build branch that people should only commit bug fixes and new protocols that don't need changes outside the protocol proper? Possibly just use the release branch, and make actual releases a tag on it?
Not clear what the names should be, but we should sort out whether we want to do this first.
One of the issues we saw was people going to the nightly just to get bug fixes or protocols that weren't available in 4.0.1. I think many of those people would have been better off with a build based on the release + bug fixes and protocols. So could we get an automated build branch that people should only commit bug fixes and new protocols that don't need changes outside the protocol proper? Possibly just use the release branch, and make actual releases a tag on it?
Not clear what the names should be, but we should sort out whether we want to do this first.
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4402
01 May 2016 16:14 - 01 May 2016 16:15 #47554
by PhracturedBlue
Replied by PhracturedBlue on topic New automated build branch?
effectively you are talking about the BRANCH_5.0. I am not sure there is any benefit to it right now. I'd like to do point releases more often (and I've provided you instructions to do so when I inevitably disappear again). I don't think protocol development should be done on this branch. Development should all happen on master, and results should be pushed to BRANCH_5.0 when they're stable. If users are testing experimental protocols, it is probably okay to have them on master (master should never be non-functional). Once the protocol is ready, move it to BRANCH_5.0 and make a point release.
Last edit: 01 May 2016 16:15 by PhracturedBlue.
Please Log in or Create an account to join the conversation.
- silpstream
-
- Offline
Less
More
- Posts: 244
01 May 2016 19:20 #47562
by silpstream
Replied by silpstream on topic New automated build branch?
Hi guys, sorry if this is something obvious or documented somewhere. I couldn't find anything on it.
From what I understand of your above 2 posts, BRANCH_5.0 is for the official release and all development will happen in the MASTER branch, after which things from MASTER will get merged into BRANCH_5.0 for a new release with an increase numeric tag. If so, are the nightlies built off of MASTER?
Thus for SOP, a developer should:
Thanks!
From what I understand of your above 2 posts, BRANCH_5.0 is for the official release and all development will happen in the MASTER branch, after which things from MASTER will get merged into BRANCH_5.0 for a new release with an increase numeric tag. If so, are the nightlies built off of MASTER?
Thus for SOP, a developer should:
- Pull the latest code from MASTER to their own fork
- Create a branch in their own fork for the new feature
- Make a pull request to "deviationtx/deviation" when the feature is ready
- If accepted, the pull request gets merged into MASTER with other pull request potentially
- If bug is found, do we fix our fork and issue another pull request, or do we pull the latest from upstream again and treat bug fixing like feature creation above?
- If a few developers are getting pull request accepted simultaneously, how can we isolate specific bug fixes or stable features to merge into BRANCH_5.0? A few commits into MASTER from different features could have gone on that needed conflict resolution, with bug fixes sent in following other feature/bug fix merges.
Thanks!
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4402
01 May 2016 20:58 #47568
by PhracturedBlue
Replied by PhracturedBlue on topic New automated build branch?
master is the main development line. It is where we do major development for the next big release.
BRANCH_5.0 is for bug fixes and minor enhancements. These are safe changes that do not break backwards compatibility.
nightlies are currently only built off of master (which is what this discussion is about). it is quite possible that a bugfix needs to be implemented differenty for master and trunk, so it isn't necessarily as easy as fix it in master and move to BRANCH_5.0. So generally there would be a pull request for master and a separate one for BRANCH_5.0 I don't know how frequently we'll release 5.0.x point releases. It depends on how many changes come. I also don't know how minor an enhancement needs to be to get included in the 5.0 branch. For instance, can a new protocol go into BRANCH_5.0? Almost certainly. Can support for a new transmitter go into BRANCH_5.0? possibly. Can a change to the ini syntax go into BRANCH_5.0? Probably not.
You seem to think our developer base is larger than it is. Development is generally done in private repos and merged into trunk only when it is of sufficient quality. Rarely do developer commits collide.
My recommended work-flow is to create a branch for a specific feature from your cloned master repo. develop and test there, then make a pull request from your branch back to the main repo. This allows you to keep unrelated changes separate, and makes it more likely your pull request is accepted. you can upload test builds to our test-build site easily if you want users to test changes before they are merged.
BRANCH_5.0 is for bug fixes and minor enhancements. These are safe changes that do not break backwards compatibility.
nightlies are currently only built off of master (which is what this discussion is about). it is quite possible that a bugfix needs to be implemented differenty for master and trunk, so it isn't necessarily as easy as fix it in master and move to BRANCH_5.0. So generally there would be a pull request for master and a separate one for BRANCH_5.0 I don't know how frequently we'll release 5.0.x point releases. It depends on how many changes come. I also don't know how minor an enhancement needs to be to get included in the 5.0 branch. For instance, can a new protocol go into BRANCH_5.0? Almost certainly. Can support for a new transmitter go into BRANCH_5.0? possibly. Can a change to the ini syntax go into BRANCH_5.0? Probably not.
You seem to think our developer base is larger than it is. Development is generally done in private repos and merged into trunk only when it is of sufficient quality. Rarely do developer commits collide.
My recommended work-flow is to create a branch for a specific feature from your cloned master repo. develop and test there, then make a pull request from your branch back to the main repo. This allows you to keep unrelated changes separate, and makes it more likely your pull request is accepted. you can upload test builds to our test-build site easily if you want users to test changes before they are merged.
Please Log in or Create an account to join the conversation.
- silpstream
-
- Offline
Less
More
- Posts: 244
01 May 2016 21:09 #47569
by silpstream
Replied by silpstream on topic New automated build branch?
Thanks for clarifying! Silly me, for not realising there was a test-build site. Makes much more sense now. 
Please Log in or Create an account to join the conversation.
- mwm
-
- Offline
02 May 2016 13:39 #47583
by mwm
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Replied by mwm on topic New automated build branch?
So one possibility would be to do automated builds off of BRANCH_5.0. Not official releases since they are automatic, but not with the risk inherent in the nightly builds either. Call them "beta" or "release candidate" or something?
And since I touched on names - can we get the version on the nightly build changed? Giving them the same version number as the last release can cause some confusion. We don't really have any semantics for version numbers, so we can split them out any way we want. I'm thinking something like 6.0.0-xxxxx for the current nightly, then 5.1.0-xxxxx for what I called the beta, and 5.0.1 if we do a release that doesn't come out of the beta builds.
And since I touched on names - can we get the version on the nightly build changed? Giving them the same version number as the last release can cause some confusion. We don't really have any semantics for version numbers, so we can split them out any way we want. I'm thinking something like 6.0.0-xxxxx for the current nightly, then 5.1.0-xxxxx for what I called the beta, and 5.0.1 if we do a release that doesn't come out of the beta builds.
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Please Log in or Create an account to join the conversation.
- Thomas.Heiss
-
- Offline
Less
More
- Posts: 698
02 May 2016 16:33 - 02 May 2016 16:47 #47592
by Thomas.Heiss
Replied by Thomas.Heiss on topic New automated build branch?
Thanks for this suggestion Mike!
+1
I do not like it as well as that the nightly builds start with the same version as the last release.
Between 4.0.1 release and 4.0.1-xxxxx nightly-build version number was 2 years.
Talking about a concrete release number on the forums or Mantis just confuses...
Nightly-build is pretty much everything else but for sure the trunk/default/master development and latest changes / enhancements has IMHO nothing in common with any 4.0.1 or 5.0.1 bugfix release or 5.1 release candidate of the branch 5.0.
As we are talking about it: Mantis bug tracker:
Is there any way to have an additional version field for the Mantis bug tracker form which is searchable too (including search result) where people could enter:
release 4.0.1
[stable] release e.g 5.0.0
(bugfix/stable) release 5.0.x
release candidate (RC) 5.x.x
nightly build (current development) with what version number
+1
I do not like it as well as that the nightly builds start with the same version as the last release.
Between 4.0.1 release and 4.0.1-xxxxx nightly-build version number was 2 years.
Talking about a concrete release number on the forums or Mantis just confuses...
Nightly-build is pretty much everything else but for sure the trunk/default/master development and latest changes / enhancements has IMHO nothing in common with any 4.0.1 or 5.0.1 bugfix release or 5.1 release candidate of the branch 5.0.
As we are talking about it: Mantis bug tracker:
Is there any way to have an additional version field for the Mantis bug tracker form which is searchable too (including search result) where people could enter:
release 4.0.1
[stable] release e.g 5.0.0
(bugfix/stable) release 5.0.x
release candidate (RC) 5.x.x
nightly build (current development) with what version number
Last edit: 02 May 2016 16:47 by Thomas.Heiss.
Please Log in or Create an account to join the conversation.
Time to create page: 0.038 seconds
-
Home
-
Forum
-
Development
-
Development
- New automated build branch?