[questions] - About Release 3.5

[SkavenKF]

Hi YF Team, i have some questions about the steps to the next release.

• In #3763 it was said that there are 3-4 packages out there until the 3.5 release and the 3.5 package will be released at the end of the year.
• Among milestones is the 31.12.2016 as a delivery date.
• We have 32 open Bugs since 2. Aug. assigned to release 3.5

When you would fix the bugs in 3.5? What is your timeline to 3.5? Is there a release strategy for the planned 4.0 LTS Release in 201x, with hotfixes?

I look forward to your answers :-)

[KatarzynaUlichnowska]

Hello!

1. New version will bring a lot of changes in the engine because one of our big customers required us to rewrite the communication with data base (previously, the system could only work on MySQL and now it also works on PostgressSQL and EDB and in the future it's going to work on Oracle and MsSQL). For that reason, we had to rewrite several thousand queries.
2. Additionally, we've optimized loads of mechanisms in the system, so that the system can work for 3.000 users online and remain stable and fast.
3. Within 2 months, we added over 1100 changes to the system and every day we fix bugs.
4. Changes at GitHub will be probably fixed before the release of next stable version.
5. New stable version (3.5) will be most likely released at the end of January and before that we will release 2-3 testing packages that will allow the update and testing.
6. Version 4.0 will be released a few weeks after 3.5.

[SkavenKF]

Hi, great news. :smiley:

I think with these elementary changes it is all the more important to test and correct errors. I hope, as soon as the first test package is available, these are also available in the release branch (gitmaster?) for testing. In my opinion, we should then only focus on error correction and not introduce new functions or processes.

You write under point 4 "... stabIe and fast." Do you mean that in future (4.0 LTS) to provide something like the critical bug #3748 as hotfix, there is unfortunately until today (to 3.4.21) nothing official to it. (and thus 3.4.0(21) is not so stable) :confused:

[KatarzynaUlichnowska]

3.4 + fix is stable. The fact that there is a bug in the system that is critical to you doesn't mean it is critical to everyone else. If no one insists on creating fix2, then there isn't any. If it was really critical to many people, there would be already fix2.

[gogroup-official]

3.4 + host fix is'nt stable, so many bug :(

3704 #3697 #3727 #3739 #3710 and more

[SkavenKF]

If a crm is used correctly, the error with the currency fields is critical. I believe every management would immediately take action when reports deliver false sums. So i think #3748 is critical, not only for me! (Or no community member used this productively :unamused:)

[bpabiszczak]

Every software that I know has bugs in stable versions and in some systems bugs aren't fixed for many years despite the fact they were reported [e.g. in Windows]. When we release a stable version, we check reported issues at GitHub and search for important bus. If there aren't any, we publish a new version. All the time you can access a testing version at https://gitdeveloper.yetiforce.com/ and if you want a new version to be free from bugs, you should test it instead of only complaining.

If we find an important bug in a stable version, a customer doesn't see it because they are found in functional tests and fixed (we upload fixes at GitHub). GitHub isn't a place for fixing every single bug reported by the community but it is a place for cooperation. If you want to treat us as your employees, you won't be satisfied because we mainly fulfil tasks that we are paid for by our customers and as secondary we fix things for free for our community.

It will be like that until we assign a dedicated developer for the community. Then, the community will decide what and when he should do. However, developer's salary will be from donations but right now there are hardly any donations..

I close this issue because it isn't a place for such a discussion. If you want, you can start a new discussion.

[SkavenKF]

Every software that I know has bugs in stable versions and in some systems bugs aren't fixed for many years despite the fact they were reported [e.g. in Windows].

Hmm, ok, I thought you wanted to be better than any other software. I'm concerned here are critical errors, which do not make the product (release) usable. But clear that is my view.

When we release a stable version, we check reported issues at GitHub and search for important bus. If there aren't any, we publish a new version.

no comment ...

All the time you can access a testing version at https://gitdeveloper.yetiforce.com/ and if you want a new version to be free from bugs, you should test it instead of only complaining.

Sorry, i test yetiforce from beginning (and translate). The problem is that there is for example no beta version, which one can test. There are still a lot of functional changes just before a release that makes reasonable testing and reporting impossible.

If we find an important bug in a stable version, a customer doesn't see it because they are found in functional tests and fixed (we upload fixes at GitHub).

Concretely, I'm concerned with critical errors (for example, currency bug) and how you deal with this in the announced LTS release. It is not about EVERY reported error! (For example Windows: Microsoft regularly provides patches not new releases ) 😄

GitHub isn't a place for fixing every single bug reported by the community ...

but what?

... but it is a place for cooperation.

Exactly, therefore, I also want to contribute my share within my possibilities and make the German translation

If you want to treat us as your employees, you won't be satisfied because we mainly fulfil tasks that we are paid for by our customers and as secondary we fix things for free for our community.

Sorry, that was understood so, I only wanted to help and support you to get a good and stable version (also the community version) :disappointed_relieved:

It will be like that until we assign a dedicated developer for the community. Then, the community will decide what and when he should do. However, developer's salary will be from donations but right now there are hardly any donations..

The curse of open source software ... I think if there are clear requirements and also a transparent cost overview, then there will also be sponsors (for example, MS Office Integration costs xxxx € and includes the following features)

I close this issue because it isn't a place for such a discussion. If you want, you can start a new discussion.

You are right, a forum would be better for discussions ...

Do not misunderstand my comments, I find yetiforce is a good product and your support is also very good compared to other opensource products. Actually, I would just like to help and point out if I think a hotfix is needed to make the community version a success and continue to grow.

But ultimately it's up to you what you make of it ... :wink:

[bpabiszczak]

The problem is that this bug affects you and you don't fix it. It isn't related to us because when we deploy or migrate the system, we immediately fix all bugs reported by our customers. This problem doesn't exist to us because a fix has been uploaded to gitdeveloper. The problem isn't the fact that there in no fix, but the problem is that it hasn't been easily delivered to you. When we come across such a bug, we fix it and when you come across it, you write and ask for fixing release cycles of the system and create a fix-patch for you - don't you see any anomaly in it?

In YetiForce, we added unit tests [TravisCI] and we perform manual tests. Every single day, we add fixes to the system and they aren't only our and our customers' fixes but also fixes for the community. Right now, there aren't any plans to release any Alpha, Beta, RC, RC1, RC2, RCn versions because our team is too small to "cleave" versions. If you need an ALPHA version, you can download a GitDeveloper version and treat it as ALPHA. Download it again in a week time and treat as BETA. We cannot say that the way we release versions is the best but we think that it is the most suitable to our team and its possibilities.

How much time do you think is required to prepare a fix-patch? I think it's about 1 hour, so why no one from the community has created and published it? No one also paid for preparing it. The problem is that everyone takes care only of their issues and not of what they can do for the others.

[SkavenKF]

Thanks for your answer and for reopen the issue For my "currency bug" i have create a hotfix patch, based on your fix at gitdev, some weeks ago. But where can i publish this? (in my repository or in "UpdatePackages")

Right now, there aren't any plans to release any Alpha, Beta, RC, RC1, RC2, RCn versions because our team is too small to "cleave" versions. If you need an ALPHA version, you can download a GitDeveloper version and treat it as ALPHA. Download it again in a week time and treat as BETA.

Exactly as I did it at the beginning, a problem were the test data. Is there a way to have automated test data created, or to generate which at the installation? Another problem are functional changes just before a release, which make many tests meaningless.

[SkavenKF]

I have upload my Hotfix for the currency bug Hotfix @community: please test and give Feedback 😃