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. On Sat, Apr 4, 2015 at 10:19 AM, Sean P. DeNigris <[email protected]> wrote: > stepharo wrote > > there is a huge time / energy investment problems. > > I don't see it. The simplest thing (which is 0 extra work AFAICT) would be > to tag the last version before we start updating for 5.0 as something like > 'Pharo-4-final'. Almost as easy would be to have a branch per version, so > e.g. typos could be merged back if someone was interested. But maybe I'm > missing something - where specifically do you see the time & energy > investment? Because I think we could've set it up in less time than it took > me to write this reply! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p4817525.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >
