release-management

I have a few open source projects that I manage. I've been posting the .tar.gz releases for them to a directory on a webserver I run. I would like to post them to github. Is there a simple way to post the release and a signature for the release? My users aren't sophisticated enough to download the release with git; they want to download and install a .tar.gz file. Some of them may even want to verify the signature. GitHub have just announced their new "GitHub Releases" feature, which sounds like exactly what you're after: https://github.com/blog/1547-release-your-software One nice option

I work for a product development company.We first do internal releases,and then public release.I was wondering, how other product developing companies manage their release? How do you give release number? Tag the source control? Kevin We use SubVersion, where tags and branches are cheap to create. As far as releases go, we follow this convention: (Major Release).(Minor Release).(Patch Release).(SVN revision) Patch Release = bug fixes Minor Release = binary compatible / interface compatible Major Release = includes breaking changes. Does that make sense? If you need more information, add a

Do you have to deploy the .pdb file with compiling under release? Why does it even compile a .pdb when you do a release build anyway? JaredPar No you do not need to deploy them. As to why they are even built in release. A PDB file really has a couple of uses but the primary ones (at least for me) are Debugging Profiling Both of these tasks are validly done on release binaries which is why release builds include a PDB. In fact, when debugging Watson dumps it's 100% of the time against a release build. Without a PDB I would have to resort to looking through dissasembly :( You don't have to

When I look in the SVN log I really wish I could see markers that tell me when releases were done. I've seen this in other version control systems such as PVCS and Perforce . Can this be done in SVN? I've done a little bit of research and so far it looks like this sort of thing is not supported. Edit We don't want to have to copy our source to a different folder for each release. This results in a huge amount of unnecessary duplication of files on the developers machine and only gives us a record of the revision number of each release. I can do that using a text document! Edit2 My goal is to

Our software product line requires developing and maintaining multiple software versions concurrently. We are relative Git newbies and recently adopted Git Flow to take advantage of Driessen's branching model . We have a very small software team with few dedicated developers (we all wear many hats) and no "integration guru." Much searching has turned up little specific advice on how to adapt Git and Git Flow to our needs. What has turned up is that Git Flow is not well suited to supporting multiple versions concurrently. One related discussion on SO has answers indicating separate branch names

UPDATE: example repository, https://github.com/so-gitdemo/so-gitdemorepo In the context of the github repo. How can I easily locate rev "b0430cee"? I know I can just look, but the real example that this repository mimics has a dozen committers and multiple other branches. Not quite as easy to use inspection. How can I find the branch creation revision when the branch has been merged multiple times? I am aware of this question: How to determine when a Git branch was created? The solution does not appear to work for a branch that has been merged multiple times. We typically merge bug fixes back