You are not logged in.

Dear visitor, welcome to Jabaco - Community. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.



  • "Faldegast" started this thread

Posts: 25

Date of registration: Oct 6th 2009

  • Send private message


Wednesday, October 6th 2010, 10:54am

Time to make an commersial release?

I know that in the instant that there is a stable Jabaco i can start making money, and that means that i can pay for Jabaco licenses, support and services. This is possibly my most important point so i will move it to the top. This makes it a little out of context but you are developers so you should be able to read it. :D

There are a lot of fuss about switching from VB6 now so this is a good time to give the users an alternative.

I know that Jabaco is not perfect. However i have tested it a lot and it is the BEST tool for porting VB applications to another platform, so i will vote that its ready to be commercially released.

There are commercial tools out there that are a lot less sophisticated then Jabaco and very expensive. Jabaco offers a integration with a modern language (Java) that is unmatched by the competitors. It is also unmatched in the way most of the code just compiles and runs because of the close syntax compatibility. In this it offers the most painless way to move from VB6

My suggestion is that the development branch (the beta) is forked to 2.0 and only important patches is backported to 1.0. New features should not be added to 1.0 nor its fork of the framework after this point. Even if it contains incompatibilities with VB 6 such patches should only be introduced if they cannot interfere with existing Jabaco 1.0 code.

Perhaps a keyword to specify Jabaco 1.0 is useful. In 2.0 this keyword undo changes to language and framework that would break 1.0-compatibility. In such case this keyword should be automatically added to all files created by Jabaco 1.0.

C/C++ usually have a pragma or compiler option to specify such options, however having a language keyword is superior.

Not that i have also requested stuff like Linux compatibility. However commercial support is more urgent then any other feature i want.

To pin it down this is needed for me to create commercial Jabaco applications. I can not do that with a version of Jabaco that can have changes that breaks compatibility with existing applications.

Rate this thread
WoltLab Burning Board