Re: [Pharo-dev] A thought about backporting

[btc]

OMG! I only just noticed on the "RELEASE" page [1] the linked file "Pharo2.0-win.zip" [3] has a last-modified-date of 2013-11-13.  What crack [2] are you smoking?  A "released" file with a name like "Pharo2.0-win.zip" should NEVER change its contents.  NEVER!  It SHOULD always remain the same - always - to the end of time! Backports are really important but they should be labelled as a new version "release" or just as "latest" if regularly uploaded from the CI. There is much (good) talk about reproducibility in the Pharo development process, but what about the poor sysadmin who deals only with installing "released" versions of software?  Where is his reproducibility for the documentation he produced specifying where to downloaded the EXACT software versions required to configure the Standard Operating Environment of a business.  Documentation used by another half dozen people people who never use Pharo themselves? A later "release" in the summer should have a different name, like 'Pharo2.0-summer-win.zip".   Indeed why do you even bother calling it Pharo2.0 if there is never a Pharo 2.1 or later minor increment?  Just dispense with it and call it Pharo2 and Pharo2-summer in the filenames.  It is fantastic that latest-build is available as an installer, but don't present it to user's as a "release".  In many sysadmin situations it is better to have reproducibility with know issues - rather than randomness with some issues resolved but other new ones introduced to eat into your time investigating them. As I near the end of writing this I now vaguely remember some past discussion on this, that seemed to make sense at the time - but I'm tired and had a bad day so perhaps my eye is more critical today. Maybe I just needed *something* to vent at. I know everyone is time-poor while achieving many great things with Pharo. I do appreciate it.  I think now I'll go have a snooze. regards -ben [1] http://www.pharo-project.org/pharo-download/release-2-0 [2] http://en.wikipedia.org/wiki/Crack_cocaine [3] http://files.pharo.org/platform/Pharo2.0-win.zip Torsten Bergmann wrote: If a backport happens it can mean two things to a user: POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...) NEGATIV: a possible broken API introduced by a backport It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip" from http://files.pharo.org/platform directly after the "big announcement" and half year later (after backports happened) he may be surprised since it results in different images and may lead to problems. Not directly in the image but it can happen when loading other packages that could be broken by the backport. On one side we want a "reproducible" reliable version announced as "official release" at one point in time on the other hand we want to be able to backport fixes and make the experience better so Pharo 2.0 is not really fix. IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but for the artefacts (in the build folder) and on the download page we should provide the FULL VERSION: MAJOR.MINOR-BUILD As you know we already use this for our development: the build is our update number which is also easily reproducible (we have release mails like for 20627) and in the near future with projects like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/ it will be even easier to get a specific image version. So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way people could spot the difference to old downloads more easily. One often see's download pages of open source projects stating "Download latest here" and "Download previous versions here" with a list of older releases. By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want. My proposal: lets use the update number more often. It would also help when people report bugs to know about the specific update number. It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the newer one with the backports?" cycle ;) Thx T. Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr Von: "Noury Bouraqadi" <bouraq...@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] A thought about backporting Hi, Here is a thought I want to share with you. Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system. I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer? There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one). Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough. Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version. Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --