I agree. There is a strong need to identify versions in the documentation. They question is where to draw the line. David has pointed out that in the past its just been a matter of noting that certain functions are available 7.5.8+, etc. Do we want to keep working from that position? ie Break the documentation out to v7(-stable/-devel) v8(-stable/-devel) and then do the same 'available in 7.5.8+' syntax? Or do we want to hard lock the documentation versions to a specific release version.
The latter is more precise from a documentation perspective and less work, but the former offers less confusion on what you can and can not do with a specific version. I can see benefits to both methods, so feedback on that would definitely be helpful. -- James ________________________________________ From: [email protected] [[email protected]] On Behalf Of Rainer Gerhards [[email protected]] Sent: Sunday, December 15, 2013 5:25 AM To: rsyslog-users Subject: [rsyslog] [doc] versioning As David pointed out, we need to find version the rsyslog doc, so that each version gets its accompanying doc (and excatly the right one, as Pavel said). I suggest that we follow the scheme that rsyslog uses, which means branches for v5-stable v6-stable v7-stable v7-devel (as long as it exists) master (which is v8-devel) each release receives a version tag. I usually update the oldest branch and then merge up into the newer ones (e.g. fix necessary for v7-stable, do it there, and aplly a number of pull operations until master is reached). This method has worked out very well and saves a lot of time. I think it would be good to have at least v7-stable, v7-devel and master in the new doc repository. v5 is really dead now (at least in regard to updates), so I don't think it's worth working on it. Same for v6 - nobody uses it (and that's what I recommend). I don't know what the best approach is to import this into the new repo. If it's easy enough, it probably makes sense to import v7-devel and v7-stable and see that we get the "merge upwards" thing going (I guess there is some initial effort). That way, improvements could already be started in v7-stable. I expect that v7 will be around for quite some while, so we must work on that. It will probably be more critical to success initially than master. I probably should have stated this so clear a day ago, but I admit I had not anticipated things move so quickly ;) Sorry for that. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
