That's a big issue that will need to be handled. If I get the time, I'll look at making a mod, but orphaned child posts are not really beneficial.

IMO child posts follow the parent.  So if it is split (or moved/merge) then it should only require doing down the line and updating the id_topic (and id_board if needed).  Or in the case of perm deletion then just going down the line and removing them.

The thing is that I can't think of a good way to avoid either loading all the posts in a topic (might not be that bad if you don't get the large text fields) or using recursion (recursion the idea not the implementation).  So splitting and removal could become very costly operations.

Quote from: Thantos on September 18, 2008, 12:42:30 PM
The thing is that I can't think of a good way to avoid either loading all the posts in a topic (might not be that bad if you don't get the large text fields) or using recursion (recursion the idea not the implementation).  So splitting and removal could become very costly operations.

Agreed. You could have a query that doesn't load the actual post text to find out what ones need the update.

Either way, it would require some experimentation to handle this without killing performance.

Perhaps this is a naive question, but what exactly is the conceptual difference between threaded and non-threaded? SMF is considered non-threaded, and I see it as a tree with arrays of postings as the leaves. The levels are

root
   category 1
   category 2
      board 1
      board 2
         child board 1 (optional)
         child board 2 (optional)
           topic 1
           topic 2
              array of posts, entered at either oldest or youngest end

I've seen other boards that apparently are "threaded", but what exactly does this mean, in terms of data organization and how a visitor navigates it? If I want to follow "the thread" of a discussion, rather than the next overall posting, I click on "next in thread". How does that differ from going into a topic and following it in sequence? Logically, is it the same as a very flat tree:

root
   topic 1
   topic 2
      array of posts

presented as

latest post in topic 7
latest post in topic 12
latest-1 post in topic 7

? Personally, I find an SMF-style tree a cleaner organization than a threaded forum. Do people have trouble with a tree because they miss seeing all the latest postings in chronological order? Is it the serendipity that they want of stumbling across something they weren't looking for? Would the SMF feature of listing the 20 or so latest posts fill this need?

(insert joke here about not seeing the forest for the trees)

Quote from: MrPhil on September 18, 2008, 03:16:49 PM
Perhaps this is a naive question, but what exactly is the conceptual difference between threaded and non-threaded?

While the whole board/topic thing is organized like a tree, "threaded" refers to the post display. For a good example of threading discussions, check out any article on Slashdot.

The general idea is that each post, rather than having a position in time, also has a position relative to the other replies. A post can be the child of a different post, and would be displayed conceptually under that rather than later on based on the time posted.


Also, I just thought of another tricky scenario. What if you want to reply to more than one post (multi-quote)? I suppose you could post multiple times, once to each thread. I believe vB has some feature where you can quote multiple posts and make only one reply with your post showing in the different threads (but that could be confusing). Of course, I've never used a threaded vB, so I could be wrong in my understanding. Either way, it makes multi-quoting a pain in flat mode.

Damn, this "session has expired" bug is driving me mad! How long are they on sm.org? Ten seconds or what?

Quote from: Motoko-chan on September 18, 2008, 03:37:08 PM
Also, I just thought of another tricky scenario. What if you want to reply to more than one post (multi-quote)?

Ah, yes... I didn't think of that one, either. Maybe that's because I never used the feature
Still, I'm not sure it's a problem. You may have noticed that my code actually reproduces a single Quick Reply box for each and every post in the thread. That's both what makes the display so "heavily charged", and much easier to use than any other nested system (I have yet to see a quick reply box on thread-enabled boards, really!)

Any news or something about this???

Well, although I'm a bit more skilled at maintaining mods now, I'm not sure I would want to maintain a mod that I do not actually use on my website... It would be a hassle more than anything else for me. And I already have enough work with Noisen, SMG and possibly AEVAC...

All of the code I posted on page 1 can easily be turned into an efficient mod, but I would recommend putting the extra code into an external file and calling its functions, it would make it easier to update the mod itself... And add more functionality, such as what to do with orphan posts and double posts, etc...

Why not integrate it into the release rather than a mod or extension function?  It is a useful option that reduce the cluttering of the screen endless posts after posts, and you have no idea who is replying to who's comment.  Thread view completely eliminates that ambiguity with a tree-structure.

The issues about deleting posts is not a problem, because all it needs is relink the parent and child posts, or replace it with a "deleted pseudo post" if you want to maintain the original tree-structure.  It is not any different from how you handle deleting a regular flat view.

Besides, there are lots of forums that have both flat, threaded, and hybrid views integrated seamlessly, such as  myBB, vBulletin, etc. they don't have any of the issues raised by Motoko-chan.

I don't see why there is such a resistance to threaded view when it allows you to go through the posts much better.  If you are following the posts everyday, then you may remember what people are talking about in the previous threads.  But if you are a newcomer trying to read through a thread with a hundred replies, it is a nightmare to sort out who is replying to who.

Quote from: nicoladie on January 24, 2009, 08:32:33 PM
Why not integrate it into the release rather than a mod or extension function?  It is a useful option that reduce the cluttering of the screen endless posts after posts, and you have no idea who is replying to who's comment.  Thread view completely eliminates that ambiguity with a tree-structure.

That depends on your opinion. Quotes help a lot and flat view discourages multiple tangents. Each style has its place.

Quote from: nicoladie on January 24, 2009, 08:32:33 PM
Besides, there are lots of forums that have both flat, threaded, and hybrid views integrated seamlessly, such as  myBB, vBulletin, etc. they don't have any of the issues raised by Motoko-chan.

Because they chose a solution from the possibilities. I'm not saying it's an impossible thing, just that there are many things that come up when designing a threaded view where the handling needs to be determined. It gets even more complex when you have a "hybrid" system where you can view in either mode. Look at the rather weird handling of multiple quotes that vBulletin has. It's because it needs to know which branches to put your response on.

Oh, and if you think handling a flat-only topic is difficult where you don't know who is replying to what, try taking a highly-branched conversation and sticking it in "flat view".

Quote from: nicoladie on January 24, 2009, 08:32:33 PM
I don't see why there is such a resistance to threaded view when it allows you to go through the posts much better.  If you are following the posts everyday, then you may remember what people are talking about in the previous threads.

A major part of the current resistance is that it's actually a very low-demand feature (we've had maybe 10 requests for it versus hundreds for many other pet features). It would be rarely used (I don't know of any vBulletin boards that use the threaded view as default much less allow switching views) and add a bunch of complexity to code that would make development much more difficult. We have a small development team at the moment, and there are plenty of other features we were looking at providing that would have much more widespread use.

It's not a permanent no, and certainly I can't speak for the development roadmap, but I don't personally see it being added anytime soon (2.0 is feature-locked and future upgrades don't have feature-specific plans currently).

As for flat mode being difficult to follow, It really depends on what you are used to and how much one allows topics to wander into tangents. Active moderation including splitting topics and just keeping things going in a somewhat-unified direction help this.

Quote from: nicoladie on January 24, 2009, 08:32:33 PM
But if you are a newcomer trying to read through a thread with a hundred replies, it is a nightmare to sort out who is replying to who.

It really depends. I have not seen topics degrade into tens of tangents simply because that becomes difficult to follow for even those participating. Usually, it will either die quickly, get split out, or a new topic will be started about that tangent.

Quote from: Motoko-chan on January 24, 2009, 09:08:22 PM
As for flat mode being difficult to follow, It really depends on what you are used to and how much one allows topics to wander into tangents. Active moderation including splitting topics and just keeping things going in a somewhat-unified direction help this.

Quote from: nicoladie on January 24, 2009, 08:32:33 PM
But if you are a newcomer trying to read through a thread with a hundred replies, it is a nightmare to sort out who is replying to who.

It really depends. I have not seen topics degrade into tens of tangents simply because that becomes difficult to follow for even those participating. Usually, it will either die quickly, get split out, or a new topic will be started about that tangent.

OK, I'm still trying to get my arms around the two models: SMF-style flat and Slashdot-style threaded.  (Are those two good examples?) It's beginning to look to me like "threaded" takes the flat style:

category > board > [ child board(s) ] > topic (tree leaf) > linear list of postings

and allows users to make an arbitrary "tree" under the topic -- subtopics, so to speak. In a flat model, the tree structure is fixed (by the forum operator) and ends at the [ child ] boards, and users can add to the topics under a board (tree leaves) and to the list of postings (a linear array) under a topic. Whereas, in a threaded structure, users can change subject lines to split off a new branch topic (subtopics). There may be fewer fixed levels above this (possibly just a root, and then topic branches start from there). Is this a fair description of the two models, or have I not gotten it yet?

Anyway, to address the concern over getting lost over "who's replying to whom" within a topic, there are at least two solutions. The first is to insist on some discipline to quote a bit of the responded-to posting, so a reader can see where this reply is referring to. Using the "Quote" button, which adds a pointer back to the parent post, is a good thing. It's only necessary to quote a few key words or phrases, and not repeat the whole damned thing like some bozos do.

The second solution is to insist that, when going off on a tangent, that a new topic (thread) be started, so that the new thread doesn't get mixed in with the old. Here, it would be handy to add a button to "Start related topic" at the topic (or posting) level, rather than just a "Start new topic" at the board level. The first post (or maybe an automatically-generated "post 0") could include a pointer back to the original topic (even better, the posting where the "Start related topic" was pressed). SMF would have no data structure changes -- a child (related) topic would look just like a regular topic and could be manipulated (moved, deleted, split, combined) like any other. If something is done to its parent topic, that might leave a bad back-link, but that might be detected and cleaned up in some manner. If you also want a forward link from a posting to its child(ren) topics, that would probably require a new table and other changes to SMF's internals. It might be better to automatically generate a "see related topic" posting that includes a link to the new topic, and place it right after the topic where the "Start related topic" button was pushed (insert, if a post is being edited). This new posting might be treated like a regular "Quote" posting start, and permit the user to add some text of their own (but forbid removal or editing of the "related topic" link -- that's only for moderators/administrators). The problem there is that a user would be creating two postings (one in the old topic and one starting the new) and might get confused as to which one they're writing to (and SMF might need two editing windows showing at the same time).

Anyway, just some more thoughts on something that might satisfy the functional request for "threaded" without doing damage to SMF's internal data structure. While at the "Table of Contents" level, you would see all topics under a board in linear order, at the same level (usually sorted by date), I would think it easier to find a subject line of interest than the usual "wavy" indented threaded listing. If it's considered important enough to keep topics and their children together as one unit (sort by the latest posting anywhere in the group, and indent by level), that would either require some data structure changes or spending the time to chase back pointers and build the tree on-the-fly.

To make it simple: threaded view is best in ALL occasions, but ONLY if the thread is old and you're not participating in it.
Otherwise, getting the new posts to show up? Not easy.
But being able to split a post and all of its answers directly from a topic would be fantastic, eh. (Which is one of the top reasons why I was hoping that my starter code posted on page 1 would make someone want to do an actual mod out of it. As always, my own answer will be, "nah, I'm too busy with Aeva, and I'm not sure it'd be a good idea to support a mod I'm not currently using on my own site.")

All your code was correct, awesome that is a good work for you...

What?

More than likely a link spammer. I have removed their in-post link.

Quote from: Nao 尚 on August 18, 2008, 09:37:57 AM
Okay, let's go to work...!!

First of all, add a "id_parent" field to "smf_messages". It shall have the same format as "id_msg", since it will store the same kind of information...

In Post.php, BEFORE "// Start the main table.", add:

Code Select Expand

if (!empty($_REQUEST['quote']))
echo '
<input type="hidden" name="quote" value="', (int) $_REQUEST['quote'], '" />';

Now go to the Display template...

Add this around the beginning. (Before "is_poll")

Code Select Expand

if (!empty($context['threaded']))
echo '
<div class="tborder" id="quickreplybox' , $message['id'], '">
<h3 class="titlebg headerpadding">
<a href="javascript:oQuickReply.swap();">
<img src="' . $settings['images_url'] . '/expand.gif" alt="+" id="quickReplyExpand', $message['id'], '" />
</a>
<a href="javascript:oQuickReply.swap(' . $message['id'] . ');">' . $txt['quick_reply'] . '</a>
</h3>
<div class="smallpadding windowbg" id="quickReplyOptions', $message['id'], '" style="display: none">
</div>
</div>';

After "$ignoredMsgs = array();", add:

Code Select Expand

$increm_list = array();
$increm_list[0] = -20;
$increm_list[$context['first_message']] = -20;


After the "if ($message['id'] != $context['first_message'])" echo sequence, add:

Code Select Expand

if (!empty($context['threaded']))
{
$increm = $increm_list[$message['parent']] + 20;
$increm_list[$message['id']] = $increm;
}

$sty = $message['counter'] == $context['start'] ? 'margin-top: 0' : '';
$sty .= !empty($increm) ? (!empty($sty) ? '; ' : '') . 'display: none; margin-left: ' . $increm . 'px' : '';

if (!empty($increm))
echo '
<div style="margin-left: ' . $increm . 'px"><a href="javascript:void(0)"
onclick="n = document.getElementById(\'mypost' . $message['id'] . '\'); if(n.style.display == \'none\') { n.style.display = \'block\'; } else { n.style.display = \'none\'; } return false;">R&eacute;ponse de '
. $message['member']['name'] . ' ' . (is_numeric($message['time'][0]) ? $txt['on'] : '') . ' ' . $message['time'] . '</a>' . ($message['new'] ? ' <img src="' . $settings['images_url'] . '/new.png" alt="New" border="0" />' : '') . '</div>';


(You'll have to replace the "new.png" link, as well as add language strings for "Réponse de" which is French for "Reply by... (author name)")

Now we're starting the main div for each message... Just increment them, something like that:

Code Select Expand

echo '
<div class="clearfix ', !$message['first_new'] ? 'topborder ' : '', $message['approved'] ? ($message['alternate'] == 0 ? 'windowbg' : 'windowbg2') : 'approvebg', ' largepadding"', !empty($sty) ? ' style="' . $sty . '" id="mypost' . $message['id'] . '"' : '', '>';

Now, right before the end of that main div, add this:

Code Select Expand

if (!empty($context['threaded']))
echo '
<div class="tborder" id="quickreplybox' , $message['id'], '">
<h3 class="titlebg headerpadding">
<a href="javascript:oQuickReply.swap();">
<img src="' . $settings['images_url'] . '/expand.gif" alt="+" id="quickReplyExpand', $message['id'], '" />
</a>
<a href="javascript:oQuickReply.swap(' . $message['id'] . ');">' . $txt['quick_reply'] . '</a>
</h3>
<div class="smallpadding windowbg" id="quickReplyOptions', $message['id'], '" style="display: none">
</div>
</div>';


Now add the final div.

I usually add a "unset($increm_list);" after the message loop.

In the Quick Reply <form> stuff, I add these among the variables:

Code Select Expand

<input type="hidden" name="quote" value="" />

Now, AFTER the quick reply code block, I add this:

Code Select Expand

$a = '';
if ($context['can_reply'] && !empty($options['display_quick_reply']) && !empty($context['threaded']))
{
$a = '
<div class="smallpadding floatleft" id="warning%msg%">
' . $txt['quick_reply_desc'] . ($context['is_locked'] ? '<p><strong>' . $txt['quick_reply_warning'] . '</strong>' : '') . ($context['oldTopicError'] ? '</p><strong>' . sprintf($txt['error_old_topic'] . $modSettings['oldTopicDays']) . '</strong>' : '') . '
</div>
<div>
' . ($context['can_reply_approved'] ? '' : '<em>' . $txt['wait_for_approval'] . '</em>') . '
<form action="' . $scripturl . '?action=post2" method="post" accept-charset="' . $context['character_set'] . '" name="postmodify" id="postmodify%msg%" onsubmit="submitonce(this);" style="margin: 0;">
<input type="hidden" name="topic" value="' . $context['current_topic'] . '" />
<input type="hidden" name="subject" value="' . $context['response_prefix'] . $context['subject'] . '" />
<input type="hidden" name="icon" value="xx" />
<input type="hidden" name="quote" value="%msg%" />
<input type="hidden" name="notify" value="' . ($context['is_marked_notify'] || !empty($options['auto_notify']) ? '1' : '0') . '" />
<input type="hidden" name="not_approved" value="' . !$context['can_reply_approved'] . '" />
<input type="hidden" name="goback" value="' . (empty($options['return_to_post']) ? '0' : '1') . '" />
<input type="hidden" name="num_replies" value="' . $context['num_replies'] . '" />
<textarea cols="75" rows="10" style="width: 95%; height: 150px;" name="message" tabindex="1"></textarea><br />
<input type="submit" name="post" value="' . $txt['post'] . '" onclick="return submitThisOnce(this);" accesskey="s" tabindex="2" />
<input type="submit" name="preview" value="' . $txt['preview'] . '" onclick="return submitThisOnce(this);" accesskey="p" tabindex="4" />';

if ($context['show_spellchecking'])
$a .= '
<input type="button" value="' . $txt['spell_check'] . '" onclick="spellCheck(\'postmodify\', \'message\');" tabindex="5" />';
$a .= '
<input type="hidden" name="sc" value="' . $context['session_id'] . '" />
<input type="hidden" name="seqnum" value="' . $context['form_sequence_number'] . '" />
</form>
</div>
</div>
</div>';
$a = str_replace('\'', '\\\'', $a);
$a = str_replace(array("\n","\r"), '', $a);
}


(a "from_qr" hidden value was added recently for Beta 4, I'm not sure it should be used here as well. Would have to check.)

Now, let's skip to the Quick Reply javascript...

Replace:

Code Select Expand

sJumpAnchor: "quickreply"

With:

Code Select Expand

sJumpAnchor: "quickreply"', (empty($context['threaded']) ? '' : ',
sThreaded: \'' . $a . '\''), '

Now, xml_topic.js

Add a new line after this first one:

Code Select Expand

this.bCollapsed = this.opt.bDefaultCollapsed;
this.bExbox = 0;

Add the first line (and linebreak) below before the two lines after:

Code Select Expand

document.forms.postmodify.quote.value = iMessageId;

// Doing it the XMLhttp way?
if (window.XMLHttpRequest)

The QuickReply swap function is half-rewritten, so it's best to simply reproduce it completely:

Code Select Expand

QuickReply.prototype.swap = function (destDiv)
{
if (typeof(destDiv) == 'undefined')
destDiv = '';

document.getElementById(this.opt.sImageId + destDiv).src = this.opt.sImagesUrl + "/" + (this.bCollapsed ? this.opt.sImageCollapsed : this.opt.sImageExpanded);
document.getElementById(this.opt.sContainerId + destDiv).style.display = this.bCollapsed ? '' : 'none';
if (this.bExbox > 0)
setInnerHTML(document.getElementById('quickReplyOptions' + this.bExbox), '');
setInnerHTML(document.getElementById('quickReplyOptions' + destDiv), this.opt.sThreaded.replace(/%msg%/g, destDiv));
this.bExbox = destDiv;
this.bCollapsed = !this.bCollapsed;
}

And finally (for now), we skip to Display.php...

Add this somewhere around the beginning:

Code Select Expand

function Tri_recursif($msg)
{
global $atrier, $ordre, $parent;

foreach ($atrier as $key => $msg2)
if ($parent[$msg2] == $msg)
{
$ordre[$key] = $msg2;
unset($atrier[$msg2]);
Tri_recursif($msg2);
}
}

(Feel free to rename this function to "recursive_sort" if you'd like.)

Add these to the globals in Display():

Code Select Expand

global $atrier, $ordre, $parent;

($atrier means "to be sorted", $ordre means "order", sorry for using French-language variable names, I didn't plan to release my code in the first place...)

After the "// Duplicate link!  Tell the robots not to link this." lines, add:

Code Select Expand

if ($_REQUEST['start'] == 'threaded')
{
$context['threaded'] = true;
$_REQUEST['start'] = -1;
}

BEFORE "// If they are viewing all the posts, show all the posts, otherwise limit the number.", add:

Code Select Expand

if (!empty($context['threaded']))
{
$context['messages_per_page'] = -1;
$context['page_index'] .= empty($modSettings['compactTopicPagesEnable']) ? '<b>' . $txt['all'] . '</b> ' : '[<b>' . $txt['all'] . '</b>] ';

// Set start back to 0...
$_REQUEST['start'] = 0;
}

After these three lines, add the final line in this code block:

Code Select Expand

// Find out if there is a post before that is double ;)
$context['last_user_id'] = 0;
$context['last_msn_id'] = 0;
$context['last_parent_id'] = 0;

In the SQL request that comes next, add id_parent:

Code Select Expand

SELECT id_member, id_msg, body, poster_email, id_parent

Before "if (!empty($row['body']))", add:

Code Select Expand

$context['last_parent_id'] = $row['id_parent'] == $context['topic_first_message'] ? 0 : (int) $row['id_parent'];

Next request, same thing, add id_parent:

Code Select Expand

SELECT id_msg, id_member, approved, id_parent

Add the third line in this code block:

Code Select Expand

$messages = array();
$posters = array();
$parent = array();

Immediately after that, replace the whole while() code block with this: (there are 3 extra lines)

Code Select Expand

while ($row = $smcFunc['db_fetch_assoc']($request))
{
if (empty($first_msg))
$first_msg = $row['id_msg'];
if (!empty($row['id_member']))
$posters[] = $row['id_member'];
$messages[] = $row['id_msg'];
$parent[$row['id_msg']] = $row['id_parent'] == $first_msg ? 0 : $row['id_parent'];
}

BEFORE "// Fetch attachments.", add:

Code Select Expand

if (!empty($context['threaded']))
{
$ordre = array();
$atrier = $messages;
sort($atrier);
Tri_recursif(0);
$atrier = array_keys($ordre);
unset($ordre);
}

Skip the next request, and the request after that should add id_parent:

Code Select Expand

smileys_enabled, poster_name, poster_email, approved, id_parent,

Now, in prepareDisplayContext(), add these to the globals:

Code Select Expand

global $atrier, $ordre;

BEFORE "// Attempt to get the next message.", add:

Code Select Expand

if (sizeof($atrier) > 0)
{
if ($counter >= sizeof($atrier))
return false;
@$smcFunc['db_data_seek']($messages_request, $atrier[$counter]);
}

BEFORE "// Compose the memory eat- I mean message array.", add:

Code Select Expand

$new_parent_id = $message['id_parent'] == $context['first_message'] ? 0 : $message['id_parent']; // should id be topic_first_message?


After the 'subject' and before 'time' (but it can be anywhere else), I added this to the array:

Code Select Expand

'parent' => $new_parent_id,

In the "doublepost" subarray (this is only used in the Merge DoublePost mod, and the reason for some of my otherwise useless code additions to Display.php, so you'll have to remove these manually for an actual mod!), replace the 'postok' line with:

Code Select Expand

'postok' => !empty($context['last_user_id']) && ($new_parent_id == 0) && ($context['last_parent_id'] == 0) && $Merge_MaxLimitLength && $context['last_user_id'] == (empty($message['id_member']) ? (empty($message['poster_email']) ? $message['poster_name'] : $message['poster_email']) : $message['id_member']) && (allowedTo('modify_any') || (allowedTo('modify_own') && $message['id_member'] == $user_info['id'])),

Before "return $output;", add this:

Code Select Expand

$context['last_parent_id'] = $message['id_parent'];

---

Okay, I think we're done...

- As you can see, it's not that big a deal in terms of additions. It can make for a very manageable mod.

- As I mentioned earlier, some of my code was added specifically for Merge DoublePost, and it doesn't work perfectly either. The problem with Merge DoublePost is that you want to make sure one can't merge two posts made in a row, if the posts belong to a different thread in the topic. This is very important. I would recommend on disabling Merge DoublePost if you intend to use Threaded view at all on your board. My code also needs some polishing on this. If you want to remove everything related to MDP, just look for $context['last_parent_id'], I think that's the only related variable.

- I know for a fact that there are a couple lines (small blocks?) of code which I removed AFTER my first uninstall of the mod, so it means they're not mentioned in this post. I will have to find them later. If you're having any problems with the integration, please post here and I will try my best to help you.
Edit -- I found another piece of code I had forgotten. Hopefully this was the thing I had also forgotten to remove the first time around. Look at the beginning of the post.

its possible make it for 1.1.9?
i very happy if yes.

Nothing has changed. My code is freely available for anyone to make a mod, provided that they credit me for said code.

Quote from: Nao 尚 on May 24, 2009, 07:18:36 AM
Nothing has changed. My code is freely available for anyone to make a mod, provided that they credit me for said code.

o.k. anyone can make this for 1.1.9.
i cannot know php good.

I too would like to see this in 1.1.9. I am having to consider changing forum software to some other type for a new project.

Please note that the threaded view must be switchable within the threaded view to take to and from flat view> Have a look at hxxp:community.mybboard.net/thread-48649.html [nonactive] for an example

Julian

Quote from: tazzydemon on May 26, 2009, 07:56:27 AM
I too would like to see this in 1.1.9. I am having to consider changing forum software to some other type for a new project.

Both the 1.1 and 2.0 series are feature-frozen. There will be no additional features added in either of those series, so you'd need to hope for the version beyond 2.0.