I agree 100% that we should keep separate book versions for the corresponding Pharo versions. Specifically:
- Use the 'master' branch for the current stable version (4.0). Basically, the way things are right now. This at least won't break existing CI jobs (tests and PDF generation).
- Have a 3.0 and a 5.0 branch (or maybe just 5.0, going forward, if there's not enough demand or reason to do 3.0).
- When time comes for 5.0 release, the 5 branch gets moved to master, and the previous master gets moved to a 4.0 branch. And so on.
(Btw, I don't think it would make sense for us to use tags like 'Pharo-4-final', since the whole point about having a book under source control like that is that it's continuously improving. It makes sense to freeze software with tags (well, sort of, except you still end up making bugfix releases), but less so for books.)
I think the time / energy investment problem that stepharo was mentioning has to do with:
1) setting up the Jenkins and Travis CI jobs for the various branches. Annoying, but at least it's just an initial effort (plus subsequent bursts of effort for each Pharo version branch).
2) porting new content (or even revisions) to multiple versions. So, if a new chapter is added to the 5.0 branch in the future, is it then a requirement to also back-port it to 4.0 (and 3.0, if we have it)? (And to do the resulting small tweaks to make sure the code still works for that version, change the screenshots and so on)? This is where most of the effort comes in, as I see it. The solution is probably in relaxed expectations. We could have an implicit (or even explicitly stated in the readme) policy that new revisions will only propagate from the current version upwards (but not backwards).��
Or, even simpler, just leave it up to individual contributors' motivations -- meaning, new revision comes in, we open up tickets to back-port it to previous versions, and if somebody cares enough to do it, it'll get ported.