+1

El mié, 27-04-2011 a las 13:27 +0200, Mariano Martinez Peck escribió:
> 
> 
> On Wed, Apr 27, 2011 at 1:10 PM, Michael Forster <[email protected]>
> wrote:
>         On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker
>         <[email protected]> wrote:
>         [...]
>         > Yes, using the old version of Pharo that you used when
>         > you implemented them.
>         > Like MacOS 9 programs run on MacOS 9.
>         >
>         > If you want to run your MacOS 9 Program on MacOSX, there
>         > is for a time an emulator, and for a time some source
>         compatibility.
>         > But in the end, the only option is to port.
>         >
>         > There is no magic.
>         >
>         > You can select between
>         >
>         >        -> Inventing the Future
>         >        -> Be compatible to the Past at any cost.
>         >
>         > If what you have in the Past is valuable, selecting the
>         second option
>         > makes sense. (IBM, Microsoft). If not, then it's idiotic.
>         >
>         > We will improve this a bit in the future, but this is
>         research, so no promises.
>         
>         
>         
>         So, we mission-critical users should probably disregard the
>         mission
>         statement on the web page misleading:
>         
>            "... By providing a stable and small core system, excellent
>         dev
>            tools, and maintained releases, Pharo is an attractive
>         platform
>            to build and deploy mission critical Smalltalk
>         applications."
>         
> 
> It doesn't say anything about backward compatibility. 
> As marcus said, we want a stable system. That means it is stable. Few
> bugs, robust, etc. If you use that system for the next 5 years, it
> will continue to be stable.
> You understood stable in the sense that it won't change among
> releases?  if so, yes, the text is misleading and we need to fix it. 
>  
>         I'm sorry that I don't have time right at the moment to
>         address this
>         properly, because I do respect the efforts of the Pharo
>         developers, I
>         fully appreciate the challenges of a FOSS project, and I like
>         some of
>         the results I've seen (very nice developer UI features,
>         movement
>         towards announcements, the collaboractive book, and so on).  I
>         am
>         interested, only, in offering constructive criticism, so
>         please don't
>         mistake my tone.
> 
> Please, go ahead. And don't mistake my tone neither. I am just nicely
> discussing :)
>  
>         
>         The short version of my concern is this:  As a "mission
>         critical" user
>         of Pharo, I will trade backward compatibility for improvement,
>         if, as
>         you say, you provide "maintained releases".  Those last two
>         words are
>         the most important and incur a great burden of
>         responsibility.  I
>         don't think the Pharo project has fully considered the
>         responsibility
>         of using those two words.
> 
> We did Pharo 1.1.1 and we are planning Pharo 1.2.2. And they are
> "maintained releases". Of course, don't expect now for example, a
> maintained release in Pharo 1.0. 
> At least not from me. This is open-source. Nobody pays. Resources are
> limited. So...if you need something in Pharo.1.0 NOW, you take the
> image and you integrate the fix by yourself. 
> Or you can kindly ask. Crucial bugs are always included and
> integrated. 
>  
>         
>         The short version of my recommendation is this:  Have a look
>         at the
>         FreeBSD release engineering process.  
> 
> how many developers are working in FreeBSD?  how much money they
> receive?
> It is not that we do this because we want. Resources are limited and
> we need to use where we think they are used better.
>  
>         They break backward
>         compatibility all the time, but, if I have a mission critical
>         application running on 4.5, I will still get essential bug and
>         security fixes for a few years, and I can run trials with 8.0
>         on my
>         other servers.  
> 
> If people ask us, we are not going to do a new release for Pharo 1.0.
> However, if someone comes and say, "hey, please, can you consider
> create a Pharo 1.0.XX with the fixed issues A B C F R". 
> Sure we can do it.  What you should not expect is:
> 
> - new developments to be included in old version
> - non critical bugs to be included in old versions
> - that you won't have to change anything in your apps in order to
> upgrade to a new pharo version
>  
>         Moreover, they have an updated documented roadmap that
>         I can look at to determine that I should continue to run 4.5
>         on that
>         one box while testing 8.0 on the others.
> 
> 
> We don't need to exaggerate. Pharo position about this topic was from
> the VERY beginning. In fact, it was created just because of that.
> Now...it is already  like 3 years and 3 big releases. I am not aware
> of someone who needs to migrate and couldn't.  So...it is working fine
> for the moment.
> 
>  
>         
>         
>         Best regards,
>         
>         Mike
>         
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com
> 

-- 
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx




Reply via email to