UpdatedPharoByExample for 3.0, 4.0, 5.0
Would it make sense to freeze the documentation for each image version? Maybe a branch per image? This way, people who choose/need to work with previous image versions have an accurate reference. From my limited Git experience it shouldn't be much extra work. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I agree it makes sense, we can use git tags , or branches. Having separate docs for every version is how it works for all other languages I have used. Its zero extra work. I dont know about the generation of pdfs though, I am not familair with CI / Jenkins and how easy it is to assign specific builds to git tags / branches. On Sat, Apr 4, 2015 at 4:04 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Would it make sense to freeze the documentation for each image version? Maybe a branch per image? This way, people who choose/need to work with previous image versions have an accurate reference. From my limited Git experience it shouldn't be much extra work.
----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
there is no technical problem. there is a huge time / energy investment problems. We will reintroduce in pillar the possibility to run tests. and we will add support (should check what stephan did to get automatic scrneeshots). Stef Le 4/4/15 15:04, Sean P. DeNigris a écrit :
Would it make sense to freeze the documentation for each image version? Maybe a branch per image? This way, people who choose/need to work with previous image versions have an accurate reference. From my limited Git experience it shouldn't be much extra work.
----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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-tp4817514p481752... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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 <sean@clipperadams.com> 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-tp4817514p481752... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
My point is not related to technical issues. Just plain time to update the contents. Stef Le 4/4/15 16:19, Sean P. DeNigris a écrit :
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-tp4817514p481752... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
stepharo wrote
My point is... Just plain time to update the contents.
Iâm not suggesting we commit to maintain previous versions. But simply place a flag in the ground before we start to update for the next version. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p481786... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Ok this is easy. Le 6/4/15 19:42, Sean P. DeNigris a écrit :
stepharo wrote
My point is... Just plain time to update the contents. Iâm not suggesting we commit to maintain previous versions. But simply place a flag in the ground before we start to update for the next version.
----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514p481786... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Dmitri Zagidulin -
kilon alios -
Sean P. DeNigris -
stepharo