OK, let me come to a conclusion ;) What Michael writes and Raoul suggested makes an awful lot of sense. Right now, I have two problems:
a) we are still having a bit of trouble with the git transistion of rsyslog - I hope to have that sorted out soon b) I need to invest some time to fully understand how git branches. The bigger problem is probably b). Thankfully, I have started to work with git on librelp and it was a very good experience. It still looks like I need to invest at least a day or two more into getting fully involved with it. That doesn't sound much, but there is a lot I can do in rsyslog in this time. I think I will proceed as follows: For the next few weeks, I'll use the scheme that I outlined this morning. It works and it is sufficiently clean for the time being. Especially as I don't see any reason for gaps, there is no such major overhaul in sight. While I do so, I'll get more acquainted to git and see how I can make utilize its branching capabilities. At some point in time (and if everything works as well as advertised, what I assume ;)), I'll switch to the git feature branch strategy. My hope is all this can be done in the next 10 weeks or so. I hope I don't disappoint anyone - but the problem is things to do. All needs to go by priorities and, quite honestly, TLS or the new config file format is higher on my priority scale than the branching strategy. And, yes, I know good knowledge with git will save in the long run. But I need to start somewhere ;) I someone has serious concerns on the route I am taking, please scream now ;) Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of Michael Biebl > Sent: Friday, April 04, 2008 12:02 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog version numbering > > 2008/4/4, Rainer Gerhards <[EMAIL PROTECTED]>: > > > 2008/4/4, Rainer Gerhards <[EMAIL PROTECTED]>: > > > > > > > > 999.2.0 - stable > > > > 999.3.x - big overhaul feature, stabilizing > > > > 999.5.x - .3 + next focus feature, stabilizing > > > > 999.7.x - .5 + next focus feature, stabilizing > > > > 999.9.x - devel > > > > > > > > Again... comments please ;) > > > > > > I think you really should try to use git feature branches for > that. > > > Have a stable and master (development) branch, and develop the > > > features in separate topic branches feature-A, feature-B etc. > > > Whenever one feature is ready, merge it into master. > > > This way, it doesn't matter which feature you have to concentrate > on > > > is released first (no skipped version numbers!). > > > The strong merge suppport in git would also allow to cherrypick > easily > > > from the different feature branches or merge between them. > > > > > > Sounds good, but a honest question (NOT trying to give a bias, just a > > problem description): > > > > While I implement FocusFeatureX, I get Feature 1, 2, 3 requests and > > implement them - all while FocusFeatureX is being developed. Where > do I > > apply these? And don't I get into trouble if that interferes with > things > > that I do in FocusFeatureX? Remember, I change a couple of hundered > > lines all over the project on a typical day... > > Say you work on a featureA branch. Now you get an unrelated feature > request for featureB. > You'd switch back to current master, and branch of featureB, starting > to work on that. > By the end of the day, say featureB is ready, you'd merge those branch > back into master (and delete branch featureB if no longer required). > If featureC is dependend on featureA, you can branch from there. If > you now work again on featureA, and later on featureC, you can merge > the new commits from featureA back into featureC again. > Later, when featureA and C are ready, you merge them into master again. > For small changes, I'd directly work on master and commit there. There > is also a nice feature called git-stash, which allows to put > uncommitted changes away, work temporarily on other stuff, an get back > to the uncommited stuff later. > > I'd say, just test git and try to get a "feeling" for it. That > probably helps to make a better decision. > > Cheers, > Michael > > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
