1.6 branch
Opened this issue · 8 comments
Hello,
as discussed on IRC meeting on wednesday, should we open a 1.6 branch for reference guide according to this guide:
http://www.bitflop.com/document/116
?
We have a copy of the 1.6 docs somewhere (I think in svn). I'm fine with those docs being moved into GitHub
I'm fine with it to but not volunteering to do it :-).
The thing is though that presumably we would want to check in the original reST versions of the docs into github, rather than the generated HTML versions of the files, and that would imply that we also need to make available the build script for conversion. It just sounds like a lot of work for no gain.
Since the entire moin history was imported to git we would just need to go back through the master branch history until finding the commit where it was used to generate the 1.6 docs and then create a new branch from that point. That said I don’t really think this is a good idea; maintaining two sets of docs is hard enough right now…
Oh, good point, I had forgotten that we imported the history, but I do see (for example) https://github.com/dojo/docs/commits/master/dijit/Calendar.rst?page=3 going back four years.
So we could make branches or tags of each release for the past four years, but since we'll probably never update anything before 1.7 the value is dubious.
OK, I'm going to close this. We can always create branches/tags later if we change our minds.
Ok. Thank you. If someone will miss 1.6 docs he can find most of the infos in 1.7 branch for now.
I thought the reason for doing this was because we were going to remove the non-AMD examples in even the 1.7 branch. If we're going to keep those in 1.7, then I guess the point is moot. That said, I thought the idea was to keep versions alive for 1.6 and newer on the site, and given that there will be maintenance releases for 1.5+ to support new browser versions, it seemed worthwhile to me to have a way to update those docs. Yes, those updates would likely be rare (and few and far between), but if we set things up for 2 versions, it doesn't seem like that much effort for 3 versions, etc.
I don't remember agreeing to removing the non-AMD examples from 1.7, although I'm not opposed to it. I stopped arguing when we reached consensus to remove the non-AMD examples from master, since that's the more important task.
I was assuming the 1.6 docs would be running on the old codeglass infrastructure, like they were before they were accidentally removed, not on the rstwiki and codeglassMini infrastructure used by 1.7. Hence, 1.6 would be hard to update and even hard to generate. I suppose if the 1.6 (and 1.5?) docs were generated just like 1.7 and 1.8, then it wouldn't be difficult to maintain them.
(But I'm still not volunteering today it as there are many more important tasks.)