On Tue, 21 Oct 2014, PICCORO McKAY Lenz wrote: > I think for gambas 3.7 the changes between versions must stop (preferable), > so then the repository can be able to stable across time.. > > i note in mocosoft like proyects that manyority of programs (99% excepts > for frameworks versions implementations) works between versions of visual > basic ... > > in gambas only older can compile and run with newer but newer mades does > not compiles or run in olders, ok its similaqr to .net framework dependency > but i refers to source codee.. > > in mayority of jobs, manpowers must concentrate in funtional parts of > proyect , and tecnical parts goes to second plane and be abstract behing > the funtional parts.. > > if i must have in constant update of my code respect the changes of gambas > ... my concentration in funtional part does not goes well .. due in > enterprices the time its a mandatory vector with no fallback point
How about you *pretend* that Gambas stops changing by fixing a Gambas version for your projects? I see, the server my personal university webspace lies on runs on a kernel based on 2.6.18, with an apache which shows a 2.2.3 version number. I personally run TDE 3.5.13 (although R14 on another machine) which was *installed* on my system in 2012. (Maybe I shouldn't say that... :-)) I don't see how a code freeze would help Gambas in particular. It's not a project with that overwhelmingly many contributions per time. I didn't experience a svn conflict in over two years (as a measure of scattered changes) and at no time too many open bug reports -- which means that developers are responsive, i.e. *not locked up* adding features. And just because it's code freeze time, doesn't mean more bug reports will arrive from people. So, as I see it, this means a code freeze brings useless relaxation on the project's progress. (And progress is allegedly a good thing. You don't usually (at least where I'm from) hear people say "man, I stick to Gambas 3.2, from there it gets only worse".) But I really don't know about these management-ish decisions. I'm widely open for arguments and corrections here! All I want to say is, from my personal point of view, *if* someone is just too lazy to change some bits[*] in your software once a year (because that was the time between 3.5 and 3.6!), that's really not a valid reason to proclaim a stop on active development. Regards, Tobi [*] I can't remember fatal changes from 3.5 to 3.6... But I may be wrong here, too. It's been an entire year! If you want, please list a few of the incompatibilities you encountered through the versions. If I take the changes done from 3.5 to 3.6 on the official examples as a measure of how compatibility-breaking the version transition was over time, I can say that it wasn't much. This is yet another spot where unit testing would be a good thing to have! :-) -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user