[Gambas-user] Release goals for 3.7 / 4.0

Tobias Boege taboege at ...626...
Tue Oct 21 20:22:18 CEST 2014


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




More information about the User mailing list