comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » How to create a stable "package" in IDL?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: How to create a stable "package" in IDL? [message #85325 is a reply to message #85322] Wed, 24 July 2013 12:43 Go to previous message
Phillip Bitzer is currently offline  Phillip Bitzer
Messages: 223
Registered: June 2006
Senior Member
I typically use Git for this. (Used to use Subversion, but since all the cool kids use Git these days....here I am.) Easy to setup multiple branches. I typically have (at least) these branches:

1) master - used for stable releases
2) develop - where I tinker
3) rc - release candidate - when I think my tinkering is enough
4) bugfix??? - a branch for each bug. Gets merged into master.

The (bare) repo is on a server all interested parties can access. Developers have a choice to checkout whatever branch - their files are updated with that particular branch. No worrying about IDL_PATH.

End users are only supposed to checkout the master branch.

When I'm tinkering, I branch off the master into the develop branch and get to work. Sometimes, I'll even branch off the develop, depending on how nutty I'm feeling. Sometimes these changes get merged back into the master, and result in a new release. Other times, the changes weren't worth it and the branch is thrown away.

When I release a version of the code, I tag the master with the version number and release into the wild.

The IDL Workbench implementation of Git is rather limited (the version of eGit packaged is outdated), so I typically use the Workbench to keep an eye on which branch I currently have checked out. I use SourceTree to handle all Git push/pull/merge/etc in a GUI, although you could certainly do it at the command line.

Here's a typical workflow, starting from some stable release in the master branch:

1) Branch from master to develop. Start working on some algorithm improvement. Other developers can do the same thing.
2) After I'm happy with my tinkering, merge the develop branch to the rc branch. Let others that want to do some beta testing work checkout this out and use it.
3) Fix bugs in the rc (and maybe even in the master - which is still the previous release). When it's stable, merge this into the master branch. Tag it, and let end users know a new version is available.

Hopefully, this rambling is understandable. I know others around here use Git as well - maybe they can provide a different/better way....
[Message index]
 
Read Message
Read Message
Previous Topic: List of called subprograms
Next Topic: Plotting arrays where data points can have varying colors

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 16:35:05 PDT 2025

Total time taken to generate the page: 1.36105 seconds