We understand that perfectly. Now for us we get money now and may be not the same in the future. Then there are the things that - must be done and consume a lot: 64bits, uFFI, - super important to do git - also super important: cleaning and improving the system. So we pay attention for backward compatibilities but we cannot cover everything.
Stef On Fri, Jul 28, 2017 at 3:13 PM, p...@highoctane.be <p...@highoctane.be> wrote: > Changing too many things at once is indeed annoying. > > Now, I am ready to live with that but at one point, I think that we will > have to move to something like I see done in other fast evolving ecosystems. > > In Hadoop for example, Hortonworks (a distribution) moved to a set of slow > evolving substrate that is stable and know to stay stable for a long period > (HDFS, YARN) and a set fast moving releases for projects that do build on > top (Spark). > > Holding back on the new things makes you feel like you use a tool of the > past. Living on the bleeding edge is not doable because you need to solve > too many non business centric issues. > > There needs to be a combination. > > As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship, > embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop > production code on it at the moment. 7.0 looks okay but there are lot of > changing things there, so, that is also too much for me. > > 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large > collections. I need a platform I can understand and build upon. > > There needs to be a semblance of LTS in this. > > Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not. > > 6.x is a great platform and has a lot going for it if stable enough. > > I have projects coming my way and using Pharo is an option. Now, I need > something that is not going to shift under my feet. > > Especially if I want to embark crew along. > > Phil > > On Fri, Jul 28, 2017 at 11:00 AM, Serge Stinckwich > <serge.stinckw...@gmail.com> wrote: >> >> >> >> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <hila...@drgeo.eu> wrote: >>> >>> I don't share your enthusiasm. >>> >>> I once set up a satisfactory build environment for DrGeo, based on P3. As >>> long as I stay with P3, I can concentrate on DrGeo code: write the code, >>> then fire up a build script to deploy the application. Now porting to P6 is >>> a pain: the infrastructure to deploy a desktop application has not evolve >>> since P3, I have to build again a deployment environment from scratch (VM >>> support, shrinked/built image, I don't know the promise of minimal image >>> build up is not palpable for me). >>> >>> Now If I have to spend days on that, I am not sure I will do it again, I >>> can't compete against other geometry application if I have to fight against >>> pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry >>> to make it explicit but I can't much offer to do both. >> >> >> I have sometimes the same concerns with Pharo or some tools of the Pharo >> ecosystem. I know that we are trying to do our best and regarding the number >> of core developers we have already an incredible platform. But sometimes, >> you need to very simple updates and because of subtle problems with >> VM/configurations/CI/ etc ... this is not that simple and we need to spend >> times on boring stuff. >> >> There is no simple solution. >> >> One solution might be that the core developers only focus on core Pharo >> functionalities but I think this is somewhat difficult, because most of the >> dev are from RMOD. RMOD is a research unit and could not spend all his >> money/effort on an engineering process. >> >> Another solution is to grow our community. More people, more companies to >> sustain more engineers through the consortium. The more people we are able >> to attract, the more people will help to develop working solutions for >> problems like deployment or to have bug-fixing intermediate releases. >> >> This is why we all need in the community to do as much as possible >> advertisements: lectures at universities, talk to your colleague about >> Pharo, do demos in companies, at open-source forums, use Twitter do talk >> about Pharo ecosystem, the software you are developing with Pharo. >> Don't hide problems but talk about our nice platform and our community. >> >> We have done this with Stephane in the early days of Pharo at open-source >> forums in France and I remember that you come in the community after we meet >> you in one of these forums :-) >> So DrGeo2 exists because of this kind of advertisement. >> >> Regards, >> >> -- >> Serge Stinckwich >> UCN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ > >
