When will 0.3.15 release?

[eersoy93]

Hi friends!

When will 0.3.15 release? I want a new version of ReactOS.

Thanks for answers.

[Yaraslau]

In 2013.

[SomeGuy]

When it's done.

[DOSGuy]

Possibly never. The next release could be 0.4.

[jonaspm]

Possibly never. The next release could be 0.4.

TRUE, everything points that the devs are gonna skip the 0.3.15 release and will try to fix most blocking bugs to launch the new 0.4.x family

[Dave3434]

so were moving into beta faster? nice

[Z98]

Has any developer actually said any such thing?

[DOSGuy]

I thought it was supposed to be alpha until 0.5 anyway. Even if they release 0.4 tomorrow, 0.5 would be released in 2020 if 0.4.x lasts as long as 0.3.x did!

[fred02]

Even if they release 0.4 tomorrow, 0.5 would be released in 2020 if 0.4.x lasts as long as 0.3.x did!

You meanie.

[eersoy93]

I thought it was supposed to be alpha until 0.5 anyway. Even if they release 0.4 tomorrow, 0.5 would be released in 2020 if 0.4.x lasts as long as 0.3.x did!

Yes, development is very slow.

[hbelusca]

Well, it will be released when the Memory Manager will be fixed (at least).

[PascalDragon]

I thought it was supposed to be alpha until 0.5 anyway. Even if they release 0.4 tomorrow, 0.5 would be released in 2020 if 0.4.x lasts as long as 0.3.x did!

Yes, development is very slow.

Why does everyone relate development speed with released versions? The main mesasure should be commits. E.g. in Free Pascal we only release a new major version every two years (which is considered slow by some users), but nevertheless the development activity in trunk is high (afterall all features and bugfixes are done there first).

Regards,
Sven

[EmuandCo]

God, how much i 2nd that...

[livestrong2109]

Seriously If you compare 0.3.14 and the current trunk builds the differences far exceed anything done between the last two release builds combined. 4.0 when released will be a real show stopper for many of those that have been following the project. The real issue with our release cycle has been in regards to drawing a clear line in the sand and calling it a release. We have far exceeded many of the requirements for a release several times over. However other reasonable bugs or lack of implementation have made such a release impractical, as it would reflect badly on the project. Fireball and the rest of the team have made the correct decision in the face of constant pressure to provide evidence of progress, and while I'll admit there is room to improve in that regard things are without a doubt moving along just fine.

If you want to see what the current state of ROS looks like then download a Trunk Build - There are new ROS builds released all the time, you just need to know where to find them.

Trunk Builds - http://iso.reactos.org/

[BlackRabbit]

I am still new enough to ReactOS to have clarity of perspective on what needs most improvement (besides the MM). Or at least I think I do.

It seems to me that the greatest impediment to rapid development has been the somewhat-sub-optimal development cycle.

I had two excellent engineers "in my pocket", ready to contribute to ReactOS development, but when they discovered that Visual Studio integration was effectively non-existent, they waited to join. These people are professionals, like most of us, very busy, like most of us, and would like to make effective use of their time, like most of us. After a few weeks...well, let's just say that they will not be helping us. There are three others who are more "flexible", and I am waiting for full Visual Studio integration for those three. Then there are some my of old students whom I could recruit, but I would really want to make sure their development-cycle experience is near-perfect, because I know some of them have very little patience for "administrative" type work.

Some of you might say:

Well, if they are so sensitive about minor defects in the build process, then they should not be hacking an OS.

I think this is a very dangerous attitude. A better attitude might be:

Wow..I did not realize that a stream-lined development cycle was so important that it would cause a potential contributor to disengage. We really need to fix this.

Fortunately, lately, due to the work of Amine and others, Visual Studio integration is getting closer to completion.

The same philosophy goes for debugging, which is part of the development process. It should be possible to use Visual Studio 2012 in a host machine to debug ReactOS in a guest VM in real-time, find the bug, edit, compile, link, push-out theEXE, debug again; all automatically, without ever leaving the comfort of the IDE.

Finally, once this development cycle is normalize, we can make effective use of ReactOS veterans in the following way: The veterans would break-up the work-load into small pieces. I have not used JIRA, but my guess is that JIRA would work. The idea here is to capture those developers who want to help, but have too many responsibilities in their private lives. If you tell one of these developers....

Oh...yea...I am not clear where the bug is...or even if there is a bug...why don't you do this...and that...and that...download this..set this setting...

That would be too much.

But if you serve their work "on a silver platter", then you can get that C/C++ professional engineer, super-busy father of 3 small children, etc. etc. because he would be able to get-in quickly and get-out quickly.

I am certain that the bug is in win32k.sys. We have made the development cycle so easy with Visual Studio, there is nothing to think about except the bug itself. All you need to do is pull from SVN, hit build, execute, with break-point set at this line in this file.

That's a key, in my opinion, for scaling the effort. Make it so that contributors do not have to marry every aspect of ReactOS, to help ReactOS