I want one release version and a debug version of the same files.
Right now I have written a python function that creates the two versions. Is there a more idiomatic way, maybe directly supported by waf?
Yes, waf use "variants" to manage such things. See ยง7.2.2 of the waf book
Related
If I want to enable a new piece of functionality to a subset of known users first, is there any automated system of framework that exists to do this?
Perhaps not directly with version control - you might be interested to read how flickr goes about selectively deploying functionality: http://code.flickr.com/blog/page/2/
And this guy talks about implementing something similar in a rails app: http://www.alandelevie.com/2010/05/19/feature-flippers-with-rails/
Most programming languages have if statements.
I don't know what "switching between them at runtime" means. You usually don't check executable code into an SCM system. There's a separate process to check out, build, package, and deploy. That's the province of continuous integration and automated builds in agile techniques.
SCM systems like Subversion allow you to have tags and branches for parallel development. You're always free to build, package, and deploy those as you see fit.
As far as I know no...
If you wanted a revision control system that had multiple versions that you could switch between. Find a SCM you like and lookup branching.
But, it sounds like you want it to me able to switch versions in the SCM programmatically during runtime. The problem with that is, for a revision control system to be able to do that it would have to be aware of the language and how it's implemented.
It would have to know how load and run the next version. For example, if it was C code it would have to dynamically compile and run it on the fly. If it was PHP it would have to magically load the script in a sandbox http server that has PHP support. Etc... In which case, it isn't possible.
You can write an app to change the version in the scm by using the command line.
To do it during runtime, that functionality has to be part of the application itself.
The best (only) way I can think of doing it is to have one common piece of code that acts like a 'bootloader', which uses a system call to checkout the correct branch based on whatever your requirements are. It then (if necessary) compiles that code, and runs it.
It's not technically 'at runtime', but it appears that way if it works.
Your first other option is something that dynamically loads code, but that's very language-dependent, and you'd need to specify.
The other is to permanently have both in the working codebase (which doubles your size if it's a full duplication), and switch at runtime. You can save a good bit of space by using objects that are shared between both branches, and things like conditional compilation to use the same source files for both targets.
I want to make paid and free versions of my app. I want to structure things so that I can build one version or the other with as few changes as possible. As far as the source code is concerned, this is easily accomplished by having a BOOL constant isFreeVersion somewhere, and referring to it as needed.
But how should I set everything else up? Obviously the App ID will have to change, and this will in turn entail changing some build settings in XCode. What is the best way to keep that to a minimum?
You could use a preprocessor flag (in your Xcode build settings) to switch between the two. The flag can be used across your source code using simple preprocessor directives (e.g. #if IS_FREE_VERSION ... #endif) in a manner similar to an if statement. This will help you avoid build scripts.
The disadvantage of this approach is that by default each time you build, the last build product gets overwritten.
In term of version control in general, I wouldn't recommend using branches unless the impact of building two versions means important code changes between the two set of sources.
If you can have only one set of sources (with your BOOL constants), that means the rest must be managed through building script, which would:
take a parameter to know if it has to build the free version or the paid version of the executable (no parameter means it builds both)
use one XCode build setting or another, depending on the version it has to build.
I have a situation where i need to maintain version information of my builds. By googling i found limited information. one way is to create a version file on source control and keep updating. other is to use the source control revision number. final one is to use bamboo build number. i haven't implemented anyone of this before. colud anyone point out the pros and cons of each method.
Thank you,
Reddy.
Please atleast tell me which method have u used to implement the same.
Thnq..
Visit http://confluence.atlassian.com/display/BAMBOO011/1.2.1+Using+Custom+Variables for more information about bamboo variables.
Remember to define a system property in your job configuration like this:
-DbambooBuildNumber=${bamboo.buildNumber} then you can use this property bambooBuildNumber in your maven or ant configuration file.
Good question. I've done this in kind of an ad-hoc manner before. I don't strongly advocate the following approach, but I'll list it anyway for comparison with the (I hope) better approaches that others will soon be posting.
In order to maintain the version information in a medium sized Java codebase, I created a simple class to hold the major, minor, and revision version numbers as static constants and produce a formatted version string. I then created a perl script to check the class out of version control, replace the version components with those specified as arguments to the script, and check it back in.
The script does most of the work, so the process of updating the version is fairly simple and quick. I had to implement this quickly, so there are probably better ways of doing it. I just didn't have time, or motivation, to research better alternatives.
I'm not entirely sure what your question is but I'm assuming you want build numbers? When you build your project with Ant you can use the BuildNumber task to keep track of build numbers.
you can use ${bamboo.buildNumber} in ant
look at the following thread
http://forums.atlassian.com/thread.jspa?messageID=257319944
The following link is a pretty good article. If you can get all the plugins working with the version of Bamboo you're on it should be fine.
Release Management with Atlassian Bamboo (outdated)
Release Management with Atlassian Bamboo via the Internet Archive
Putting development tools (compilers, IDEs, editors, ...) and runtime environments (jre, .net framework, interpreters, ...) under the version control has a couple of nice reasons. First, you can easily compile/run your program just by checking out your repository. You don't have to have anything else. Second, the triple is surely version compatible as you once tested it. However, it has its own drawbacks. The main one is the big volume of large binary files that must be put under version control system. That may cause the VCS slower and the backup process harder. What's your idea?
Tools and dependencies actually used to compile and build the project, absolutely - it is very useful if you ever have to debug an issue or develop a fix for an older version and you've moved on to newer versions that aren't quite compatible with the old ones.
IDE's & editors no - ideally you're project should be buildable from a script so these would not be necessary. The generated output should still be the same regardless of what you used to edit the source.
I include a text (and thus easily diff-able) file in every project root called "How-to-get-this-project-running" that includes any and all things necessary, including the correct .net version and service packs.
Also for proprietry IDE's (e.g. Visual Studio), there can be licensing issues as this makes it difficult to manage who is using which pieces of software.
Edit:
We also used to store batch files that automatically checked out the source code automatically (and all dependencies) in source control. Developers just check out the "Setup" folder and run the batch scripts, instead of having to search the repository for appropriate bits and pieces.
What I find is very nice and common (in .Net projects I have experience with anyway) is including any "non-default install" dependencies in a lib or dependencies folder with source control. The runtime is provided by the GAC and kind of assumed.
First, you can easily compile/run your program just by checking out your repository.
Not true: it often isn't enough to just get/copy/check out a tool, instead the tool must also be installed on the workstation.
Personally I've seen libraries and 3rd-party components in the source version control system, but not the tools.
I keep all dependencies in a folder under source control named "3rdParty". I agree that this is very convinient and you can just pull down the source and get going. This really shouldnt affect the performance of the source control.
The only real draw back is that the initial size to pull down can be fairly large. In my situation anyone who pulls downt he code usually will run it also, so it is ok. But if you expect many people to pull down the source just to read then this can be annoying.
I've seen this done in more than one place where I worked. In all cases, I've found it to be pretty convenient.
What are the advantages/disadvantages of using postgresql compiled from source compared to the ubuntu postgresql package? Which of the two are recommended to be used on a live production environment?
Thanks in advance.
I'd recommend distribution provided package over self-compiled one. You'll get automatic security updates from your distribution, sane file locations and ability to verify or restore files using your package manager. You'll be able to rollback failed update fast using old package, etc.
If you'll compile yourself you'll have to very often check if there is new version available with security updates, you'll forget what options did you use for compilation and if you mismatch them then an update can make your data unreadable. You won't be available (on vacation) when new security update is published and your update will be late. Or you'll forget to update at all. You're lazy and you'll have to work more.
I know this is an old question, but there is one very real advantage to building from source. If you find a bug, submit it to the pg mailing lists, and get a patch you can apply it within a few hours, easily. I know this, because I've done it twice in the last two years in production.
The only advantage with compiling it yourself is that you could optimize the build yourself with different features and/or compiling modes. But on the other hand this means your build is much less tested then one distribution via the package system. So doing it yourself might end up not being so great. Plus updating/redoing it as Tometzky mentioned, end up being a lot more work. Unless it's very needed to build it yourself, then don't.
(this is not specific to postgresql, but everything in a production environment)