I've recently started working on my own project, I've added to project to github and I'm learning the reigns with using a source repository.
I have some questions as much of this is new to me:
Version numbers. How do I decide what qualifies as a new version? I work on the project daily
and make many small changes. do I write down a changelog? Should I add this with every version? What's Common agreed Practice?
What are the requirements and criteria for an Alpha buuild?
What are the requirements and criteria for a Beta build?
Since you are using git, use the commit history as your change log. Just make sure you are writing short but descriptive messages.
Most of the software I write is uses Major.Minor.Revision for my visioning.
Major - Software version. This will only increment if I make a huge
change to the code base or rewrite it all.
Minor - Release. This
changes when I merge changes from the development branch to the
master.
Revision - Patch number. this will constantly be changing,
this is how many times I have pushed to the branch since incrementing
the Minor.
An example would be:
1.0.0-dev -> 1.0.1-dev -> 1.0.2-dev -> 1.1.0-rc & 1.1.0-dev
Should I have to make a hot fix I would release 1.1.1-rc and 1.1.1-dev.
As for the requirements for alpha/aeta, you can set your own criteria but normally alpha is usually where you add features to your code and fix the major issues, and beta is where you fine tune your code.
Some good references that go into more detail than I have are:
http://en.wikipedia.org/wiki/Software_release_life_cycle
http://en.wikipedia.org/wiki/Software_versioning
Related
If I have to change the source code of an app(Email, Browser, etc) for some custom requirement, I wonder how I should maintain the changes so that I can upgrade to the newer version of the app later when it's available.
I can thinking of maintaining the diff patch and applying to the newer version later but I am wondering if there are any best practices. Is it good to just fork off a branch and keep merging the newer changes into it?
Thanks.
Sony several times described their process. Here is the links:
http://developer.sonymobile.com/2013/07/25/explaining-the-software-upgrade-process-and-its-improvements-for-android-4-3/
http://developer.sonymobile.com/2011/12/07/ice-cream-sandwich-from-source-code-release-to-software-upgrade/
You should follow the disciplines that:
Keep your modifications aside from the original code as much as possible - this will save your effort if you have to do merge code later
Record your modification work in an appropriate way, you need to know why you made these changes and how you did it.
Don't expert to do a simple merge since the changes might not be fast-forward. Rebase your repository first and pick your changes and apply carefully.
I am part of a team that releases versions of our software 4-5 times each year to our customers. We maintain the previous 2-3 versions of our product by correcting any errors that we come across in later versions. We are using TFS 2008 for source control and are trying to find the best way of maintaining the older versions.
We currently create a branch of our application each time we do a new version, but we are looking for a good way to update old versions more easily. For example, we complete 9.5 but two weeks after we created the branch and are working on 10.0, we realize that 9.5 has an error. We currently make the change in version 10.0 and then open 9.5 to make the change again. Is there anyway of automating this?
Thanks!
This is a main reason for branching and merging.
What I do in your situation is to make the change in 9.5 and then merge the change up into your main branch, and then back down into your 10.0 branch. The built in merge tool works well for this.
If you go the other direction you run the risk of adding new 10.0 stuff into your 9.5 branch when all you want is your bug fix.
I would also take a look at the TFS Branching Guides for more information on branching and merging.
If you are creating a branch of your main source, then you should be able to make the correction to the bug in your main source and then "merge" that change to your 9.5 and 10.0 branches. That's part of the beauty of branching, namely, you can merge your changes from your main branch to the target branches.
When you choose the merge option with TFS, it will show you where the current source is branched, and you can choose which branches you want to merge those changes to. You shouldn't have to make the changes in your 9.5 and 10.0 branches manually, that really sort of defeats the purpose of branching in the first place.
No, there is no way to "automate" this, and you dont really want to. What if the fix doesnt really need to be applied to each version?
It does sound to me like you are applying fixes backwards (first fix in older versions, then merge to newer).
a bit of background first...
I am setting up a versioning numbering system for our project which currently only has a development branch, but we are now moving towards our first deployment. We are using TFS and we use nightly builds on our dev branch.
The way we are probably going to go with this is that when we get ready for a release we take a branch off dev and call it 1.x. This shall be a test branch: we test it, fix it (then merge back to dev), test it some more then when it is all good we take another branch off the 1.x branch and call it 1.0. It is this branch that gets deployed to production. Any fixes in production will be made to the 1.x, tested and then a new branch 1.1 will be made.
My issue is with the testing of the 1.x branch. Before testing the branch will be locked for obvious reasons. My issue is that QA requires that a round of testing be conducted against a "version number" and if testing fails the next round of testing will be against a new "version number." Us developers want to tie the "version number" to the release and testing can iterate over that version...so there is a conflict here.
My first thought is to use the build number as the point in time that the code is tested against. When its time to submit a new version for testing, the 1.x branch is locked again and a build is kicked off and the VSTS number that is generated becomes a "release condidate 1 for v1.0." Mapping the RC to a build we can do manually in a spreadsheet...
...then someone mentions labels, and that the code should be locked labled and built prior to testing. I have never used labelling before and have just read that build itself creates a label in TFS.
I am now confused about what is the best way to go here. Is using a build number for a release candidate enough? Does manually labelling serve any purpose here (the only benefit I can see is that we can give it out own name and description)? Can I tell TFS NOT to create a label whenever it runs a build and just do all our own labelling at significant points in time (not every build is going to be a release candidate for example)? If so, is NOT creating a label after each build a bad idea, what does labelling give me?
I guess I am confused about where changsets, build numbers/names and labels all fit in with one another...
This is a broad question but its one of those ones where I am not 100% sure what to ask. Any help appreciated.
...then someone mentions labels, and that the code should be locked labled and built prior to testing. I have never used labelling before and have just read that build itself creates a label in TFS.
What you have read is correct. With TFS (unlike, say, SourceSafe), every server action constitutes a 'known point in time' which can later be referred to. You can see what I mean by doing a Get Specific Version... and looking in the Version dropdown: in TFS 2005 the relevant ones I see are Changeset, Date, Label. Now, as you correctly say, every build automatically creates a label. This means that at any future time it will be possible to retrieve the code exactly as it was after any given changeset; at any given date; and when any specific label was applied, thus including when any build was done.
The upshot is that you can use your own labels or not, entirely at your own discretion - the ability to retrieve a given snapshot of the code will be there anyway. I wouldn't suggest trying to inhibit TFS from producing a label for each build (I don't know if this is even possible) - labels cost you nothing.
Your branch 1.x is a consolidation branch which will contain many incremental small evolutions.
Locking the branch is not the answer.
Setting a label (specifically named "for QA test", and locked in order to not be able to move that label, is the usual way to signal the QA team they can build their own workspace and retrieve that exact label.
Then they can begin their tests against the code.
Creating a label after each build is not always practical, since not every build is meant to be tested by QA.
We have many projects that use a common base of shared components (dlls).
Currently the development build for each project links against dlls built from the trunk of the components. (ie trunk builds use the dlls from other trunk builds)
When we do a release build, we have a script that goes through the project files and replaces the trunk references to specific numbered versions of the components (that are built from a tagged branch)
I think this weakens the testing that we do during development because the project that I am actually working on is using diferent dlls to what the release build will be using. I would like to always develop against the numbered versions of the components and only ever update them when there is a specific need.
However others in the team argue that unless we develop against trunk (and update to the newer versions of the components with each release) we will have the problem that (a) our products will hardly ever update to the newer version of the components then (b) when we do need to update it will be a huge task because the component source/interfaces will have changed so much.
What practices do you follow, and why?
Edit: Sorry all, I have just realised I have confused things by mentioning that there are several main products sharing components - although they share the components they don't run on the same PCs. My concern relates to the fact the because the components are likely to change with each release of a product (even though there was no specific requirement to update the component) that testing would miss some subtle change that was done in a component and not related to the specific work being done on the product.
Hmm, I may be in a minority here, but this comes down to release management.
Developing against the trunk of a set of shared components means, by definition, that the components are a "moving target" -- a developer using those shared components won't necessarily know if a newly found defect or failure is due to the project code or the shared components, which leads to a loss of productivity, IMNSHO.
The "shared components" have a release cycle all their own. Give your other developers a break and fix the version of the shared components that the projects are going to use and use tags, labels or branches to identify the shared component release. On the next iteration for the projects, bump up to the latest "stable" or "production" build of the shared components.
There's another "smell" here, if you'll pardon the expression. Having "shared components" whose "source/interfaces will have changed so much" between project releases sounds like the components aren't so solid or shouldn't necessarily be shared.
See also the answer to this question Shared components throughout all projects, is there a better alternative than svn:externals?
You should have strong interfaces that rarely change, so changing versions shouldn't be that hard.
Separating the versions and working against specific versions will increase overhead when you need to change, but it should also encourage less interface changes overall, which will help in the long term.
We develop against multiple branches and trunk simultaneously and we have chosen to build and test each branch with the code we'll be pushing out to production. I don't think it is safe any other way.
Basically, if a developer is working on trunk, all they have to do is worry about building from trunk and committing code to trunk.
Any developer working on a branch needs to build and test off that branch (there are multiple projects all branched/tagged the same build/release). When they commit changes to that branch, they must also merge those individual changes into trunk.
We expect all developers to be familiar with SCM (SVN) and to be capable of maintaining multiple branches of code. As a team we handle major framework shifts or huge code changes to minimize troublesome merging.
Two things here. First, I think you're right; you want to build against the most current development versions, not against the old versions. If you haven't already, you will see a situation in which the build-for-release blows up and you have to do an all-nighter cleaning up the diffs.
I'm personally a fan of the "commit to trunk, release from branch" model anyway. All commits go to the trunk, overnight builds or CI builds are against the trunk, and people create branches freely. When you have a trunk that meets acceptance criteria, tag a release candidate, BUT KEEP MAKING UPDATES TO THE TRUNK. If you hae a long release cycle, then you might have changes for release n+1 being added to the trunk, but ideally you should just shorten your release cycle instead. If there are changes to the trunk that shouldn't be in the released version, AND you have a problem that requires changes, create a branch against the tagged version --- and make sure you merge any changes back to the trunk once you have an actual release.
We are using the scons building system, and have our own file in the root directory which specifies what version of each library we're going to use when building the application.
That reduces the need to change version names in several locations like you mentioned.
Whether (b) is a valid argument depends on how often your shared components change and by how much. If they change often in your workplace, it might be a valid that you are "forced" to develop off the newest version. Whether that in itself is a problem is a valid question.
However, from your side of things, I don't see how you can push code into production without it being tested against the shared components being used in production. Do you do a second test cycle against the release build? Do you just pray that nothing breaks? Frankly, (b) can be reversed in these cases to support your point of view: If the trunk is different enough from the most recent tagged branch, then that effort has to be made to ensure your app works properly with it.
If your shared components are tagged often enough, then your colleagues are probably right, and it's easier to manage the incremental changes from the most recent tag to the trunk than it is to manage the change from arbitrary version X (determined at the last build) to arbitrary version Y (determined when you choose to upgrade).
I've tried using source control for a couple projects but still don't really understand it. For these projects, we've used TortoiseSVN and have only had one line of revisions. (No trunk, branch, or any of that.) If there is a recommended way to set up source control systems, what are they? What are the reasons and benifits for setting it up that way? What is the underlying differences between the workings of a centralized and distributed source control system?
Think of source control as a giant "Undo" button for your source code. Every time you check in, you're adding a point to which you can roll back. Even if you don't use branching/merging, this feature alone can be very valuable.
Additionally, by having one 'authoritative' version of the source control, it becomes much easier to back up.
Centralized vs. distributed... the difference is really that in distributed, there isn't necessarily one 'authoritative' version of the source control, although in practice people usually still do have the master tree.
The big advantage to distributed source control is two-fold:
When you use distributed source control, you have the whole source tree on your local machine. You can commit, create branches, and work pretty much as though you were all alone, and then when you're ready to push up your changes, you can promote them from your machine to the master copy. If you're working "offline" a lot, this can be a huge benefit.
You don't have to ask anybody's permission to become a distributor of the source control. If person A is running the project, but person B and C want to make changes, and share those changes with each other, it becomes much easier with distributed source control.
I recommend checking out the following from Eric Sink:
http://www.ericsink.com/scm/source_control.html
Having some sort of revision control system in place is probably the most important tool a programmer has for reviewing code changes and understanding who did what to whom. Even for single person projects, it is invaluable to be able to diff current code against previous known working version to understand what might have gone wrong due to a change.
Here are two articles that are very helpful for understanding the basics. Beyond being informative, Sink's company sells a great source control product called Vault that is free for single users (I am not affiliated in any way with that company).
http://www.ericsink.com/scm/source_control.html
http://betterexplained.com/articles/a-visual-guide-to-version-control/
Vault info at www.vault.com.
Even if you don't branch, you may find it useful to use tags to mark releases.
Imagine that you rolled out a new version of your software yesterday and have started making major changes for the next version. A user calls you to report a serious bug in yesterday's release. You can't just fix it and copy over the changes from your development trunk because the changes you've just made the whole thing unstable.
If you had tagged the release, you could check out a working copy of it and use it to fix the bug.
Then, you might choose to create a branch at the tag and check the bug fix into it. That way, you can fix more bugs on that release while you continue to upgrade the trunk. You can also merge those fixes into the trunk so that they'll be present in the next release.
The common standard for setting up Subversion is to have three folders under the root of your repository: trunk, branches and tags. The trunk folder holds your current "main" line of development. For many shops and situations, this is all they ever use... just a single working repository of code.
The tags folder takes it one step further and allows you to "checkpoint" your code at certain points in time. For example, when you release a new build or sometimes even when you simply make a new build, you "tag" a copy into this folder. This just allows you to know exactly what your code looked like at that point in time.
The branches folder holds different kinds of branches that you might need in special situations. Sometimes a branch is a place to work on experimental feature or features that might take a long time to get stable (therefore you don't want to introduce them into your main line just yet). Other times, a branch might represent the "production" copy of your code which can be edited and deployed independently from your main line of code which contains changes intended for a future release.
Anyway, this is just one aspect of how to set up your system, but I think giving some thought to this structure is important.