What is the roadmap to 0.4.0?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
Posts: 175
Joined: Wed Oct 05, 2011 7:32 am

What is the roadmap to 0.4.0?

Post by BrentNewland » Sat Apr 07, 2012 8:40 am

(Note: This is a serious topic.
Nothing in this post is meant to be offensive, rude, demanding, ignorant, etc.
I am not asking how long until 0.4.0 - I know that it will be released "when it's ready", just like most other software out there
(although my personal guess would be from 1-2 years from now, unless some more major upgrades on par with the MM happen, or if the version number is incremented randomly)
Please do not flame in this topic.
Please do not say anything negative in this topic unless you are providing constructive criticism.)

ReactOS has been on the 0.3.x branch for almost 6 years - this is the longest branch the team has worked on. Much progress has been made, many features added, many systems rewritten, many problems have been fixed, and many more still remain (after all, this is a project that can never be truly complete as long as Microsoft continues to release operating systems using the Win32 API).

Given the length of time the project has been on this branch, the recent advancements that have been made (such as the memory manager, USB, networking, wireless, etc., etc., etc.), the regressions that I have read about, the bugs that have not seen much activity for a while, and that there's no publicly available roadmap for 0.4.0 (the only one I've seen is from several years ago), I would like to start a conversation and find out what the developers expectations are for a realistic 0.4.0 release.

I feel that ReactOS is making (and has already made) sufficient progress that a major version number increment is warranted in the near future (1-2 years?), and I have seen that other users and developers have been thinking the same thing.

Blocking Problems
To help get an idea of what remains to be done, I'd like to ask for comments on what major problems are currently (or are expected to) block a 0.4.0 release.
  • I have read and been told that the Memory Manager is still somewhat unstable - this seems like something that should be taken care of before jumping up a major version, and this may take some time.
  • USB? According to this post, "Launching 0.4 without testing USB in a previous release seems too risky" (That is an good point)
  • Explorer? The last time I checked (which, I admit, was several months ago) ReactOS Explorer New doesn't even launch in ReactOS (I did just check both in Windows 7, the current Rex actually runs if you put it in Compatibility Mode for Server 2k3 with admin privileges, and put it in its own folder with notifyhook.dll, but Rex_new does nothing). Explorer has several big bugs and features not implemented (SDI/MDI settings, the up/back/forward buttons, file copying/moving problems, etc.)
  • Bugs? Many bugs from years ago (thousands and thousands of revisions ago) are likely to have been resolved by now. Will there be any push to clear out these older bugs before 0.4.0?
Features that need implemented
I'm not sure if any major features need to be implemented or not before 0.4.0. Would anyone care to comment?
  • Themes by default? Theme support has been added recently, the UI improvement would really show people how far the project has come
  • ext2? Work has been done recently, IIRC it almost boots
Anything special about 0.4.0
  • Which is planned to be more stable - the last of 0.3.x or 0.4.0? To elaborate, is 0.4.0 going to introduce a lot of new features (to go with a version increment), or will it be released as an accumulation of all the major changes in 0.3.x, with a focus on stability/bugs, to provide as a new stable base for all the changes to come in the 0.4.0 branch? Or will it be an arbitrary number change only?
  • Testing?
    • The testing time for ReactOS 0.3.14 was less than 19 days; for a major release number increment (such as 0.4.0), most projects would perform additional testing. This has not come up before because ReactOS wasn't at the point where that testing was possible, and has been on the 0.3.x branch for so long (there have been no major increments). 0.4.0 will be the first major version change in 6+ years, and doing extra testing would not only increase the impact, and the PR, but help reduce bugs in the trunk, which may help you identify bugs related to new code changes more easily.

      Perhaps I should make a side note: The ReactOS compatibility DB lists four program statuses: Running Stable, Running with Problems, Not Working, and Crash. To me, since "Running stable" is not explicitly defined, I read it as "can launch, perform its basic function, and close without crashing" (given the stage of development, that is all I expect of a program that I would call stable). I read "Running with Problems" as "Runs without crashing, but has major problems which prevent most functionality, or prevent basic functionality". For the forseeable future, "Not Working" and "Crash" statuses for programs are what I am personally concerned about, except for the Golden Apps, which should be able to run stable.
    • To continue, 0.4.0 could be a convenient time to perform additional testing because more programs should work than ever before, it should become easier to make programs perform their basic tasks without crashing, and simply because it's all happening at about the same time.
    • The ReactOS Compatibility DB has just under 1,000 programs listed in it. Testing that many programs is quite simple for me (and I imagine several/many others here). Downloading, installing, and running the program usually took me an average of probably 5 minutes per program (download them one after another, transfer them to the VM in bulk). The first step is listing the status of each program in the DB, the next one is going through the list , running the programs again (and getting logs and backtraces and whatnot), and filing bugs for all the programs that don't run (which are conveniently highlighted red and gray).
    • I believe it would be a worthy goal to try and get a large majority of Compatibility DB apps to run and close without crashing (excluding programs that rely on frameworks like java and .net due to the additional difficulty involved) even if it takes 30, 60, or 90 days to get through all the bug reports.
    • Besides testing apps, extensive testing could be done to ensure that 0.4.0 runs without extra bugs on all major different free virtual machine programs (Virtualbox, QEMU, etc.)
    • Of course, I would be among the first to volunteer when this was ready to happen (in the moderate future) and I'm sure there would be many other volunteers.

Of course, all that comes back to the roadmap itself.
  • There are likely going to be several releases between now and 0.4, what are your goals for those intermediate releases?
  • What kind of development plan are you thinking of for 0.4?
    • For example
    • Nine months before release you might have a feature freeze in trunk until 0.4.0 was released
    • Three months before release you might plan to have most the major kinks in new systems (like the new memory manager) worked out, and switch to user bug fixing mode
    • From three months until release you could engage the community to do lots of program testing and bug filing, and focus on fixing all the bugs that are possible to fix in the time allotted

Please note this topic is not about requesting any new features, just about how things will proceed when 0.4 is being wrapped up, whenever that may be. In my personal opinion, the majority of changes between here and 0.4.0 should be bug fixes (like the MM) as opposed to new features or large code rewrites, unless something major was already planned. But that is my opinion.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Yandex [Bot] and 3 guests