The future of FluxBB (Page 1 of 9)

Thank you for this interesting 'call', Conner.
Hmmm, I have some things to input here possibly, but before I go there, what other types of things for v1.2 besides UTF-8 are you thinking about?
And how significant an upgrade is it to apply UTF-8 (I have not looked into this at all)?
And I assume we are not talking about any kind of extension capability for this upgrade path, correct?

Thanks ;^)

This is certainly a decent idea and seems a lot better than stringing people along, with them thinking 1.3 is right around the corner.

My thought from the beginning is why not just go back to 1.3 beta 2, fix the bugs and anything that is critically broken, and release it? After all, that is the point of a beta. Then the current revision, with Paul's work incorporated, would be a later version to come after that (for example, 1.3 beta 2 released as 1.3, and current revision when finished released as 1.4). But I am not opposed to your idea of further developing the 1.2 branch as a intermediary version between 1.2 and 2.0.

I would like to see a new approach to development. It seems you need help, but yet, you don't want it, and have even stated in the recent past you do not want or need new developers. I think the project should be opened up more, by either a) letting anyone submit work, and having the official developers approve or rejected it, or b) designating a handful of "assistant developers", who are assigned only one or a few tickets at a time, whose work must be checked by the real developers. Also I think the refusal by a developer to use Trac is a very bad thing.

In hindsight, full page one rewrites always delay projects like this, and shouldn't have been attempted this close to 1.3's completion.

I like the idea but I'm not sure if the planning would work out. The way I interpret  it, it means that the improved version of 1.3 will be released in roughly a year. Knowing when Paul does commit his changes it shouldn't take too long (from what I've understood) to finish the actual 1.3 release. A lot of people seem to have be especially waiting for this release. Releasing a delayed, but improved version of it might not make them too happy.

I'd personally wait a bit more longer for Paul to commit his changes and polish things up for a release, extend 1.2 anyway and then develop/merge 1.3 into the new 2.0 version. 1.3 would make an excellent starting point for that.

I just think that too many people got used to the looks and feeling of 1.3 and for those, 1.2 might be a step back. They might even considering leaning over to using PunBB 1.3 instead and that's the last thing I'd like to see.

On the other hand, there's nothing wrong with the proposal. I'm glad to see some action from you dev's again.

Last edited by Kaboon (2008-12-24 07:49:32)

In my opinion you should consider adding an extension system to 1.4 because it makes lot faster to update hotfixes and install new features. I think vast majority of the community wants to see 1.3 (or 2.0) for the extension system. If you give them such tool I'm sure they won't ask you for 2.0 as much as they have done so far.

So maybe the simplest idea (maybe not the best) is to release the latest usable svn version as 1.3 (as dstroma said) so that people who are waiting for the extension system can start their project and give you developpers more time to add what features that you want to a 1.4 (2 ?) version.

Of course as i read that a lot of people are still planning on using 1.2 for quite a long time (heavily modded forums ...) you could always continue to improve it in the meantime if you have time.

Just my opinion

Oh boy, here I go... I really hope this is meaningful (useful) and not just a ramble to waste all your time....

I tend to generally agree with horus, Aabaz, and some others with similar reflections, to wit...

   I am a fan of 1.2 and have some fairly modded up 1.2 installations - to me very involved, and I bet not near as much as many others out there.
   I see migrating to a newer/upgrade forum platform very attractive, but a lot of work as well (meaning time and co$t).  The common consensus 'here' is to stay with what works for now, and give the new toy (1.3 model) we are looking at some time to ripen a bit once its out, then start moving into it.
   This could mean  waiting as much as a year once the new toy comes out.
   This does not necessarily mean totally avoiding investing in new features (mods) for 1.2, but certainly being frugal, upgrading some here and there, and only adding anything that's needed during this waiting period.

   The reason the new code base would be important to us is because it will make upgrading and modding much more viable (and possibly fun), easy to do and work with, and hopefully provide a more advanced php coded base for working and growing with.

   If the foregoing is fairly relevant in any universal sense here to this project and its users, I would think it important to look at any proposals put on the table 'within this scope of considerations'.

   Thus, if the forgoing is fairly relevant in any universal sense to this project and its users, then I would consider, and propose, the following if I were a developer on this project...

   It may bring on undue work for keeping an old thing alive, and be wasting precious energy, and even be potentially confusing and difficult for our user-base, if we try to facelift and upgrade 1.2 'too much'.  We should look to the future...
   'Facelift and upgrade too much' meaning... beyond the scope of fixing anything that breaks with it, or keeping it secure, or adding any mostly minor improvements ...that would also need to not break away from supporting the current modifiable structure (i.e., we do not want it to be breaking existing mods, and we do not want to impose upon users the need to rewrite new code for old mods that serve them, when they are going to be facilitated to be doing that with a newer base later anyway).

   I may be wrong on this next part, but from what it sounds like considering your comment, Conner, "...this would feature 1.3s extension system, some form of templates and other improvements to 1.3 we thought of after we stopped developing features...") ......1.3 currently is falling short of our (our dev team's) hopes and expectations, i.e., we are already thinking about features we want for fluxbb that 1.3 in its current base isn't necessarily going to support.   But we got this far with a new 'extensible-model' [if you will], and people are ready for it. 
    I would suggest that styling changes are going to be the easiest for the users to deal with, i.e., if we go ahead and stablize our 1.3 model, with an existing styling model that we know will have to be scrapped later, I feel this is much more acceptable, and exciting, to the end users ...to allow them to start to spread their wings with the new model-base, than to be waiting to release something just because there are going to be some styling changes that will affect extensions to some extent when the uprgraded 1.3 comes out.  Let the contributors simply upgrade their new extensions base when it comes to that and continue forward - without complicated version models of old (1.2) and new (1.3) stuff competing for our precious time.

    I would propose we (remember, I am playing dev member here) let out a 1.3 beta, with some old hat styling, and turn this model loose.  Lets continue to work on 1.4, i.e., not even bother to try to bring 1.3 out of beta because we want to spread out wings with other feature ideas in the new base model, but go for developing the features we really want, and just pass 1.3 and go straight to 1.4.  I bet cleaning up the mess afterward, meaning migrating/porting extensions for 1.3 beta over to 1.4 alpha once it hits the ground, is going to be less tedious, and probably more exciting a pathway for the userbase than may seem apparent right now.  I mean, look at them - they don't want a better 1.2, and they don't care about doing a little work like changing some styling or adjusting some extensions down the road, they are so eager to move into the new extensible model, lets turn it loose in beta, and let the better stuff come as it will.

   Well, that's my limited two-sense about it, limited in that I cannot claim to really be able to project myself very meaningfully (necessarily) into the developers circle/conversation, but the idea you and Elbekko are discussing Conner seems to me a little combersome, possibly not necessary, and, with all due respect, maybe even a little backward (from where it seems your dream is wanting to go).  Hell, I think you might even consider rolling 1.3 back a bit to attain the 1.3 beta proposed... simply boil it down to like a 1.2 that graduated to an extensions-model with utf-8, maintaining some old 'styling' basis for now, then push on to the next level as 1.4 - make that your 2010 new year's goal.

Cheers,

no no no no NO.

this will make it worseee, let the things right now be like that untill paul complete his markup css.

template system along with other updates can wait untill till 1.4.

do you know how annoying it is to update core with large mods like in 1.2.

and besides how worse can it be the css problem, i mean look at this forum running on 718 with no problems except in the viewtopic place, the closed problem.

ok i have a new very good idea:

let paul do mini css fixes the fixes the small important problems and then release beta 3. (should be release in a week at most)
and when paul complete his markup css, release RC1. (should be released at most 2 or 2.5 or 3 months)
and then bugfixes in RC2. (should be done in 3 weeks)
Then Final. (give it 2 more weeks of no bugs)

Last edited by SuperMAG (2008-12-24 12:11:25)

I was actually thinking along the lines of having separate developers for both 1.x and 2.x. But your point that we need help is just plain wrong; we can handle pretty much anything code-wise, but we're waiting for the markup changes.
Right now, nobody is stopping you from sending in patches. They've been sent in before and applied when it's possible to apply them.
And where you got the idea of a developer refusing to use TRAC, I have no idea. Paul said before that large commits make TRAC crash, so he splits them up file by file. And that he'd rather use his little spare time to actually work on code instead of messing around with SVN, I don't see the problem with that.

It doesn't have to be a year. It could be less. That all depends on the amount of work required (shouldn't be *that* much) and, as usual, when Paul is finished.

The extension system is one of those things that makes a 'small' release like 1.3 actually a 2.0 It requires a pretty big rewrite, especially in page variable handling etc.

The problem of extensibility has been there for a while, and it's becoming more and more clear that a templating system is actually quite important if we have to have extensions really succeed.

EDIT: The posts that are off-topic have been removed. Meow, please adhere to some basic common sense and read the disclaimers in a topic before posting random crap. If you keep doing this, you will be banned.

Last edited by elbekko (2008-12-24 13:26:39)

I understand, but extensions make FluxBB admin friendly, installing an extension needs a click, adding a mod gives an headache. Updating to a new version while you have an extension system takes a mass upload, updating to a new version when you must compare and manually change single files, which, personally, gives me the creep. Are you sure you can't include extensions in 1.2?

1.5 or 2.0 or whatever you want, but 1.3-final should be released, of course with finished markup work in this.

I don't think we need more feature for 1.2. Just security fix is ok. You have not powerful team (at last I think) so have to focus the work to important branch (1.3 here).

@Strofanto: No, 1.2 can't have a proper extension system, as you can already see in the current 1.3, it's far from perfect.
@liquidat0r: Not sure, we'll use the most stable version I guess But this idea is far from final.

My comment is very short and simple. I don't see any point for this to be happening even though there are lots of reasoning backing it up

Last edited by Scripter (2008-12-24 15:59:06)