what is the best way to do / maintain a version of a product ?
-
Firstly, get thee to a repository. Use whatever you like, but use one. Now use a file structure with head - the current head revision, development - branched off a version, and branch - holding each release. This structure I've used successfully:
product
+- branch
| +- v1.0
| | | +- v1.0.1
| | | +- v1.1
| | | +- user
| +- | +- head
| +- documents
| |For any major piece of work, branch to a user area and on completion integrate back. Integration to the branch lines is only for release and there should be no development there. Then have an automated build process that can pull down any line, say
product\headorproduct\branch\v1.0, build it and package it. As a super bonus, have the build process put on the version stamps to the files [left as an exercise for the reader]. This structure means you can patch any or all versions of the code and manage your code safely. But no one wants to reduce the risk do they? -
alright something new for me but will give it a go. my project is in asp.net should i go with SVN or Visual Source Safe as version tool.?
Ravi Khoda
I purposefully did not use the phrase version tool or recommend any particular repository. There are many factors that go into choosing a scheme and with the information you give it is hard to say which is better for you.
-
I purposefully did not use the phrase version tool or recommend any particular repository. There are many factors that go into choosing a scheme and with the information you give it is hard to say which is better for you.
-
Firstly, get thee to a repository. Use whatever you like, but use one. Now use a file structure with head - the current head revision, development - branched off a version, and branch - holding each release. This structure I've used successfully:
product
+- branch
| +- v1.0
| | | +- v1.0.1
| | | +- v1.1
| | | +- user
| +- | +- head
| +- documents
| |For any major piece of work, branch to a user area and on completion integrate back. Integration to the branch lines is only for release and there should be no development there. Then have an automated build process that can pull down any line, say
product\headorproduct\branch\v1.0, build it and package it. As a super bonus, have the build process put on the version stamps to the files [left as an exercise for the reader]. This structure means you can patch any or all versions of the code and manage your code safely. But no one wants to reduce the risk do they?Branching is evil and is a sign of a flawed process.
This space intentionally left blank.
-
Branching is evil and is a sign of a flawed process.
This space intentionally left blank.
Ooh! Ooh! Holy War! :-D And what, pray tell, is evil about branching off at the point you build a product so that it can be easily be maintained separately or in parallel to the head revision? TBH I have worked with various repository structures and branch to release has always seemed the easiest and most sensible to me. But what would I know after a quarter century of hacking? ;P
-
Ooh! Ooh! Holy War! :-D And what, pray tell, is evil about branching off at the point you build a product so that it can be easily be maintained separately or in parallel to the head revision? TBH I have worked with various repository structures and branch to release has always seemed the easiest and most sensible to me. But what would I know after a quarter century of hacking? ;P
Nagy Vilmos wrote:
a quarter century of hacking
In my quarter century I have never created a branch. In CMS (Code Management System for VMS) we used Classes, now in TFS we use Labels. If your tool doesn't support something like this (I'm looking at you Subversion) then you are using the wrong tool.
Nagy Vilmos wrote:
the head revision
That is totally wrong-headed thinking, which is a curse of the "Branch" mentality imposed by inferior tools.
This space intentionally left blank.
-
HI all, one of our client going to launch a 1.0 version of a product in the market in near future. as we are new with maintaining a version of a product i would like to know the best practice to take care about that. there may be new plugins/ functionality will be added to the product which may be separate module or may be interconnected with existing modules. i want to know the best practice to maintain this, from document level to code level or something else as well.
Ravi Khoda
Hello Ravi, One of the approaches would be to use Version tool like SVN (tortoisesvn.net/about.html). You can then create branches to maintain different versions of your product. Please visit the link mentioned above on the usage/details of the product. Many Thanks & Regards, Mehul Bhadricha
-
Hello Ravi, One of the approaches would be to use Version tool like SVN (tortoisesvn.net/about.html). You can then create branches to maintain different versions of your product. Please visit the link mentioned above on the usage/details of the product. Many Thanks & Regards, Mehul Bhadricha
-
HI all, one of our client going to launch a 1.0 version of a product in the market in near future. as we are new with maintaining a version of a product i would like to know the best practice to take care about that. there may be new plugins/ functionality will be added to the product which may be separate module or may be interconnected with existing modules. i want to know the best practice to maintain this, from document level to code level or something else as well.
Ravi Khoda
-
Search Code Project for versioning tools topic or something similar... there has been tons of post on this subject.
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
I have to take point with your signature...
R. Erasmus wrote:
"Program testing can be used to show the presence of bugs, but never to show their absence."
If a previously discovered bug is added to the list of tests to be run (TDD), then the passing of all tests, would include at least one case in which a bugs absence is duly identified... Maybe the specificity of such absence is an issue, but its absences, nonetheless.
-
I have to take point with your signature...
R. Erasmus wrote:
"Program testing can be used to show the presence of bugs, but never to show their absence."
If a previously discovered bug is added to the list of tests to be run (TDD), then the passing of all tests, would include at least one case in which a bugs absence is duly identified... Maybe the specificity of such absence is an issue, but its absences, nonetheless.
I think you misunderstood the (IMHO) truth expressed in the signature. You can design a test to confirm the absence of most previously identified bugs that do not depend on the timing of multiple asynchronous events. These latter can be the very devil, not only to identify and fix but to be sure that you have fixed! What you usually can't do is devise a test that shows that anything except a trivial program is free of all possible bugs.
-
I have to take point with your signature...
R. Erasmus wrote:
"Program testing can be used to show the presence of bugs, but never to show their absence."
If a previously discovered bug is added to the list of tests to be run (TDD), then the passing of all tests, would include at least one case in which a bugs absence is duly identified... Maybe the specificity of such absence is an issue, but its absences, nonetheless.
-
HI all, one of our client going to launch a 1.0 version of a product in the market in near future. as we are new with maintaining a version of a product i would like to know the best practice to take care about that. there may be new plugins/ functionality will be added to the product which may be separate module or may be interconnected with existing modules. i want to know the best practice to maintain this, from document level to code level or something else as well.
Ravi Khoda
The absolute minimum is to keep a copy of the code that went into each release. Duplicate those copies to give you a place to do continued work, for example one copy to do bugfixes to the current product, another for the new development that goes into the next release. Revision control systems give you the ability to create these copies virtually so you don't have the mess of full copies of the code lying around. At a minimum, you want to be able to put out bugfix releases while you're still in the middle of adding and debugging the new features for the next major release, so you need three copies (one to archive the code that was in the code of the actual release).
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Nagy Vilmos wrote:
a quarter century of hacking
In my quarter century I have never created a branch. In CMS (Code Management System for VMS) we used Classes, now in TFS we use Labels. If your tool doesn't support something like this (I'm looking at you Subversion) then you are using the wrong tool.
Nagy Vilmos wrote:
the head revision
That is totally wrong-headed thinking, which is a curse of the "Branch" mentality imposed by inferior tools.
This space intentionally left blank.
You can branch (to my way of thinking) if you have a legitimate branch in custom business software. A customer wants something and will from thence forth essentially have a separate product that must be maintained, hopefully using libraries to not be totally a new animal.
-
Branching is evil and is a sign of a flawed process.
This space intentionally left blank.
-
HI all, one of our client going to launch a 1.0 version of a product in the market in near future. as we are new with maintaining a version of a product i would like to know the best practice to take care about that. there may be new plugins/ functionality will be added to the product which may be separate module or may be interconnected with existing modules. i want to know the best practice to maintain this, from document level to code level or something else as well.
Ravi Khoda
ravikhoda wrote:
there may be new plugins/ functionality will be added to the product which may be separate module or may be interconnected with existing modules.
You need to decide exactly what that means. Specifically is a "plugin" going to be treated as a separate deliverable or will they always be part of the original product. An alternative way to think of this is if your "product" is on version 2.1.3 will Plugin XXX be version 2.1.3 or can it be 15.8.16? If it is a separate deliverable then that impacts your layout and can also impact your choice of version control.
-
PIEBALDconsult wrote:
Branching is evil and is a sign of a flawed process.
How do you do an emergency fix of an existing production application?
He doesn't. He changes his name and moves city to avoid them.
-
PIEBALDconsult wrote:
Branching is evil and is a sign of a flawed process.
How do you do an emergency fix of an existing production application?
That depends on the nature of the problem. It's never been an issue.
This space intentionally left blank.
-
That depends on the nature of the problem. It's never been an issue.
This space intentionally left blank.
PIEBALDconsult wrote:
It's never been an issue.
Lets make it more specific. You are working in a company with 20 developers (actual developers not support people) who actively support 8 different products. Each of those products has its own production delivery schedule and each of them goes through following QA process - Development signs off on the current code. - QA (or CM) labels a build, then tests that build - Bugs are cycled back to dev and QA/CM builds/labels/tests until an acceptable level of quality is reached. - QA then specifies a version to deliver and hands that build (the labeled version) to Operations - Operations installs that version. So say Operations is running version 5.3.14. - Development starts or has been working on the next version(s) with some goal that in the future QA will again deliver a version to production. Operations now reports bug that takes down the production server. It is going down once an hour. QA is currently in the processing of validating version 5.7.3. How are you going to fix production?
-
PIEBALDconsult wrote:
It's never been an issue.
Lets make it more specific. You are working in a company with 20 developers (actual developers not support people) who actively support 8 different products. Each of those products has its own production delivery schedule and each of them goes through following QA process - Development signs off on the current code. - QA (or CM) labels a build, then tests that build - Bugs are cycled back to dev and QA/CM builds/labels/tests until an acceptable level of quality is reached. - QA then specifies a version to deliver and hands that build (the labeled version) to Operations - Operations installs that version. So say Operations is running version 5.3.14. - Development starts or has been working on the next version(s) with some goal that in the future QA will again deliver a version to production. Operations now reports bug that takes down the production server. It is going down once an hour. QA is currently in the processing of validating version 5.7.3. How are you going to fix production?
jschell wrote:
20 developers (actual developers not support people) who actively support 8 different products. Each of those products has its own production delivery schedule
That's not too far off from where I worked for much of the 90s, but there were more developers and it was about eight customized versions of one product for at least three operating systems. By the time I started there the product was very stable and I only recall one problem that brought down production at one client site. We were using CMS, with classes, so we knew which version of which file needed to be worked on. It just wasn't an issue. I didn't even know CMS could do branches until I installed it on my own systems a few years ago. I'll also state that if you have a lot of bugs, that's also a problem in your process, and branching isn't going to fix it. If you're already entrenched in the "branches will save us" quagmire, then it's too late.
This space intentionally left blank.