Let's not allow FuBar to get to the state that TitanPanel got where it lost its creative vision as more and more people forked it after it was abondoned by its owner. FuBar is not an abandoned addon. CKK is actively evolving the addon no different than Grayhoof has evolved SCT. Hiding behind GPL to steal creative control from the owner is rediculous.
Sure it doesn't seem like a big deal right now but think this through. Play this forward in your head. When will it stop? Will it stop when people start "rocking" popular Ace2 addons like BigWigs and puts it in the svn as BigWigsRock? All in the name of avoiding duplication of Libs since they like Rock better than Ace? Or do we end this madness now and work towards the framework agnostic libraries that many of the Ace3 authors have discussed?
There is nothing to attack here.
This is not blown out of proportion.
I wouldn't even lobby for this cause if I didn't care about this community and the addons produced by it. I certainly gain nothing from this. But I am hoping to be a voice of reason on something that strikes me as a very bad precident.
"I was a friend of Jamius. He taught me one important thing, when you kill you pay for it"
Thank you Funkydude for making those adjustments... tho still now im not sure all this dialogue was worth that one minor change. i can wish things where different...
You can but it will, hopefully, not change anything.
I'm welcoming the name change and hope for a civil side-by-side existence and development of these two addons.
There's nothing wrong in doing something that's in accordance to the license (GPL in this case), and especially this is what the GPL is there for. Don't like something in some GPL'ed software? Go ahead and fork it!
Forking is a good thing. Hell, half of the Ace SVN (or my addons) would not exist without it :P
Forking is fine - code duplication is not. Trying to look apart from all the political and personal issues, the code duplication is really the problem here. Code duplication leads to duplication of bugs and support and probably will also cause confusion about which "variant" supports which plugins. The problem may not seem big right now because the code of the two variants are nearly the same. As time goes on they will divert more and more from each other and the problems will increase. Code duplication is bad for both developers and users. :(
As an example of what Bam just mentioned, ClockFu will not work with FuBar2, since it uses LibFubarPlugin-3.0 and does not have a drop-down menu (opens RockConfig instead when right-clicked).
Everyone needs to take a step back here though. The way I interpreted the forking was so that the old FuBar would still be available until the new one became more stable/had more features like LibDewdrop.
If it is indeed to have an Ace only version for all time, that will continue in its own development, then we will see lots of this.
ForumNoobA: My fubar is fubared! (hehe - I made a funny)
ForumVetA: What version of fubar are you using?
ForumNoobA: ummm..... Is there a difference? btw- why are these 2 plugins stuck to my minimap? I can't put them on my fubar! HALP PLEEZ!!!!11!
ForumVetB: Are you using FuBar or FuBar2? Could be that some of your plugins are written for FuBar and don't work for FuBar2.
ForumNoobA: Huh???? I think I'm using FuBar2 - that's newest right? It has a higher number.
(side: we should call ck's FuBar FuBar3, if FuBar2 stays in development, btw)
ForumVetA: No, FuBar2 is written with the Ace2 framework. FuBar is written with the Rock framework.
ForumNoobA: I just want my fubar to work!!! Can anyone HALP MEEE????/
ForumVetC: Then you need to make sure that you have and are using the correct plugins, libraries, etc that work with FuBar2.
ForumNoobA: is there a list anywhere? do they say what they work with? this is stupid
The next day, in a new thread....
ForumNoobB: Why don't this show up on my fubar?? See? really big annoying embedded image
ForumVetB: link to other thread
A couple of days later....
ForumNoobC: Wats the diffrence between FuBar and FuBar2?
ForumVetD: link to other thread
A week later....
ForumNoobD: Can someone please help me? I downloaded a new FuBar and now it's not showing up - all of my buttons are around my minimap.
ForumVetE: You aren't running both FuBar and FuBar2 at the same time are you?...
ForumNoobD: umm... let me check
ForumNoobD: yes! but if I only use one, then some of my plugins don't work now :(
Another week later...
ForumNoobE: HAAAALP!!! my fubar is fubared! (hehe I made a funny)
ForumVetA: oy....
This dramatization has been made possible by the BREWFEST! Drink up!
[me=Seerah]bows.[/me]
Great dramatization, and knowing that you're right about the outcome, maybe I (and others) should live with our lack of dropdowns. Thanks for making a point with humor and grace.
Perhaps it would benifit everyone if the developers made the LibRockDewdrop instead. Or a way for RockConfig to support Dewdrop (or both Ace and Rock?). I believe that's on the backburner for Ckk still. That's the thing most users complain about. I've seen very few people complain about the Libs. It happens every time there's an update to a lib version and steadily people move over to the new one. Thus you have duplications for a little while anyway (though imbedded or though externals however you decide to go). Unless you are pretty skilled at understanding how to edit the code to take Lib2 instead of Lib1.
Just think of the drama to come when Ace3 really goes alpha. There will be bugs and people will STILL stick to the old versions until things stable out. The only difference is you probably won't see people forking whatever to stay with Ace2.
I could be way off my rocker.. I like to read the drama not post on it. I do slip sometimes.
Ok sorry for my Noobness here, I have installed FUBAR and some fubar_addons , looks and works great. Last night I went to WoWace and I was looking around...Then I saw it..FUBAR2 about an hour old...I was like shoot! this has to be better then FUBAR cause there is a 2 after it....so I downloaded it. I keep seing this " RUN INSTALL.BAT ONCE TO OVERRIDE FULLY." I extracted this in my addon folder..is that all i had to do. I saw a few things that was diffrent...like my bars got moved and I still see FUBAR on my addon area of character select screen. I guess I just want to know if I installed it right?
Ckk deprecated fuBar-1.0 when he released fuBar-2.0. It is no surprise if he deprecated fuBar-2.0 with the release of the fuBar-3.0 library. Ckk is not obligated to maintain backwards compatibility with FuBar-2.0 with his FuBar-3.0 library at all. It's his addon. He is steering the addon in a direction of his choosing. Expecting him to forever provide support for your unsanction fork seems pretty illogical to me. Authors choosing to keep their modules current with the current version of FuBar may force all you FuBar-2.0 hangerson to create your own or create more ace forks. This is the risk and probable folly of forking an actively developed addon.
Honestly, I didn't check if ClockFu still works with FuBar2, since I've been using the new versions of everything since they came out. But this is what I have heard.
The way I see it, FuBar-2.0 was replaced by FuBar-3.0. Any plugins using FuBarPlugin-2.0 will still work with FuBar-3.0, as it is backwards compatible in that sense - why break everything? Give authors time to update their plugins - if they're even around to update them at all. But, why would FuBarPlugin-3.0 be compatible with FuBar-2.0? Why write a plugin for the current version and expect it to work with the old, outdated, and now replaced version of FuBar? In my mind, it is generally expected that if users are using a plugin written with FuBarPlugin-3.0, they most likely have FuBar-3.0. Hell, LibRock-1.0 is a dependency for FuBarPlugin-3.0. So, if users are concerned about running multiple frameworks, using plugins made with FuBarPlugin-3.0 just ruins that theory.
edit: in summary, old plugins *should* be compatible with the new FuBar, new plugins shouldn't have to be compatible with the old FuBar.
edit2: yeah, I'm no coder and don't know a hell of a lot about some of that stuff, but - at least the way I view the world - that's common sense.
Ckk deprecated fuBar-1.0 when he released fuBar-2.0. It is no surprise if he deprecated fuBar-2.0 with the release of the fuBar-3.0 library. Ckk is not obligated to maintain backwards compatibility with FuBar-2.0 with his FuBar-3.0 library at all. It's his addon. He is steering the addon in a direction of his choosing. Expecting him to forever provide support for your unsanction fork seems pretty illogical to me. Authors choosing to keep their modules current with the current version of FuBar may force all you FuBar-2.0 hangerson to create your own or create more ace forks. This is the risk and probable folly of forking an actively developed addon.
may i ask you a question?
can you throw in a wild guess - will this kind of attitude lessen amounts of forks (for fubar, and now for fubar plugins too)?
because it seems to me that you simply miss one important thing - people arent violating anything with branching addons. people want options, nothing stops them to get em.
one thing would solve everything - if ckk would upped the version of Rock Fubar. and leave old one as it is - everyone who wants to upgrade go and upgrade. everyone who want to stay - do so.
now one person (a good developer and i hope a nice guy too) decided that he can force others to use what he sees right, correct, rational or whatever you call it.
surprise, some people dont. they want things the other way.
and they do it how they want, without messing with anyone actually. only with some people who think that they are in power to decide what is wrong and what is right in moral aspect, since nothing guys have done violates GPL.
you dont like it - dont use it. you arent obligated.
lapalapa I am sorry for coming off like I have an attitude. That was not my intent.
I used the word "IF" for a reason. I am trying to be rational about this. Is it reasonable to fork a framework addon and expect all its plugins to be forever backward compatible? I'm not saying that this is going to happen for all FuBar-2.0 plugins but it might happen to some. Realistically would I be surprised *if* fuBar-3.0 was not backward compatible with fuBar-2.0? No. Would I be surprised *if* there were new features in the fuBar-3.0 library that are not in fuBar-2.0 that authors want to use in future plugins? No. Would I be surprised *if* authors chose to stay current with the official FuBar release at the expense of FuBar2 and FuBarAce users? No. Forking the FuBar framework shouldn't limit Ckk's choice to move the FuBar framework forward.
It seems like it stands to reason that by choosing to create a non-sanctioned fork of FuBar you are choosing to maintain forward compatibility with the official FuBar framework aren't you? How would it be FuBar3's fault if new features don't work in FuBar2 or FuBarAce? It seems like what you want to do is create a snapshot in time where all things FuBar2 are frozen and unchanged. You can get this by tagging the old addons or downloading them from wowinterface.com can't you? Isn't that the choice you are wanting? It just won't be available with WAU that pulls directly from the trunk. Maybe you could add a feature to WAU to allow users to pull from branches or tags? The bottom line is that noone was forcing you to change in the first place. Once you saw that FuBar3 hit the trunk you could have easily gone back to FuBar2 and did that thing that protected your folder from bring detected by WAU. Since you dont like it, don't upgrade. But by forking it, you should inherit the baggage of that choice. Ckk shouldn't be shackled by someone refusing to move forward with him.
You're completely avoiding one very important point: FuBar isn't just some addon. And it doesn't just have "plugins".
We're talking about major apps here like ora, bigwigs, and a whole slew of others, using fubar as a base interface... and they're not going to be rocked. While the idealist says that frameworks don't matter, the reality is that today, we end up loading doubles of a very great deal of the nonframework libraries. A lot of us care about that and don't want it.
Until these major addons have been moved away from fubar, there'll be a fubar2 kept alive. Simple as. Had it been me, I wouldn't have been in such a rush to port fubar to rock. (Then again I wouldn't have sat down and pieced together my very own framework to use for my own mods to begin with so maybe that's an irrelevant opinion.)
Mikk that's two jabs you have made against Ckk that I have seen today. Ckk didn't make Rock just for him. He may have had a base disagreement on how to evolve the Ace2 framework but given the amount of time he no doubt invested in Ace2, can you blame him for not agreeing that it all had to be scraped in order to achieve some sort of nirvana state of ultra efficiency. Continuously making jabs while actively moderating forums for drama is silly. What is the purpose of constantly fanning those flames?
You make a good point about major addon support for fubar-2.0 and it really would be silly if something in FuBar-3.0 broke those. Ckk seems to be a pretty smart guy so he probably realizes this. Those other major addons shouldn't ever have to be "rocked" if those authors dont want to. Then again hey maybe someone will port those major addons to Rock right in the trunk too! That would solve the duplicate libraries issues for you. Or maybe we'll get to that state of framework agnostic libraries afterall and noone will be impacted by duplicate non-framework libs.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Sure it doesn't seem like a big deal right now but think this through. Play this forward in your head. When will it stop? Will it stop when people start "rocking" popular Ace2 addons like BigWigs and puts it in the svn as BigWigsRock? All in the name of avoiding duplication of Libs since they like Rock better than Ace? Or do we end this madness now and work towards the framework agnostic libraries that many of the Ace3 authors have discussed?
There is nothing to attack here.
This is not blown out of proportion.
I wouldn't even lobby for this cause if I didn't care about this community and the addons produced by it. I certainly gain nothing from this. But I am hoping to be a voice of reason on something that strikes me as a very bad precident.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThank you Funkydude for making those adjustments... tho still now im not sure all this dialogue was worth that one minor change. i can wish things where different...
I'm welcoming the name change and hope for a civil side-by-side existence and development of these two addons.
There's nothing wrong in doing something that's in accordance to the license (GPL in this case), and especially this is what the GPL is there for. Don't like something in some GPL'ed software? Go ahead and fork it!
Forking is fine - code duplication is not. Trying to look apart from all the political and personal issues, the code duplication is really the problem here. Code duplication leads to duplication of bugs and support and probably will also cause confusion about which "variant" supports which plugins. The problem may not seem big right now because the code of the two variants are nearly the same. As time goes on they will divert more and more from each other and the problems will increase. Code duplication is bad for both developers and users. :(
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEveryone needs to take a step back here though. The way I interpreted the forking was so that the old FuBar would still be available until the new one became more stable/had more features like LibDewdrop.
If it is indeed to have an Ace only version for all time, that will continue in its own development, then we will see lots of this.
(side: we should call ck's FuBar FuBar3, if FuBar2 stays in development, btw)
The next day, in a new thread....
A couple of days later....
A week later....
Another week later...
This dramatization has been made possible by the BREWFEST! Drink up!
[me=Seerah]bows.[/me]
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGreat dramatization, and knowing that you're right about the outcome, maybe I (and others) should live with our lack of dropdowns. Thanks for making a point with humor and grace.
Just think of the drama to come when Ace3 really goes alpha. There will be bugs and people will STILL stick to the old versions until things stable out. The only difference is you probably won't see people forking whatever to stay with Ace2.
I could be way off my rocker.. I like to read the drama not post on it. I do slip sometimes.
sure, it is obviously not some of old wowace users trying to make a funi or put more drama in to this topic.
oh,wait...
It's not like FuBar is some random one-off. It's a linchpin of in the neighborhood of half the addons on the wowace svn.
If someone downloads a rocked fubar addon, and it can't function with fubar 2.... well... that's bad. And it's not fubar 2's fault.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe way I see it, FuBar-2.0 was replaced by FuBar-3.0. Any plugins using FuBarPlugin-2.0 will still work with FuBar-3.0, as it is backwards compatible in that sense - why break everything? Give authors time to update their plugins - if they're even around to update them at all. But, why would FuBarPlugin-3.0 be compatible with FuBar-2.0? Why write a plugin for the current version and expect it to work with the old, outdated, and now replaced version of FuBar? In my mind, it is generally expected that if users are using a plugin written with FuBarPlugin-3.0, they most likely have FuBar-3.0. Hell, LibRock-1.0 is a dependency for FuBarPlugin-3.0. So, if users are concerned about running multiple frameworks, using plugins made with FuBarPlugin-3.0 just ruins that theory.
edit: in summary, old plugins *should* be compatible with the new FuBar, new plugins shouldn't have to be compatible with the old FuBar.
edit2: yeah, I'm no coder and don't know a hell of a lot about some of that stuff, but - at least the way I view the world - that's common sense.
may i ask you a question?
can you throw in a wild guess - will this kind of attitude lessen amounts of forks (for fubar, and now for fubar plugins too)?
because it seems to me that you simply miss one important thing - people arent violating anything with branching addons. people want options, nothing stops them to get em.
one thing would solve everything - if ckk would upped the version of Rock Fubar. and leave old one as it is - everyone who wants to upgrade go and upgrade. everyone who want to stay - do so.
now one person (a good developer and i hope a nice guy too) decided that he can force others to use what he sees right, correct, rational or whatever you call it.
surprise, some people dont. they want things the other way.
and they do it how they want, without messing with anyone actually. only with some people who think that they are in power to decide what is wrong and what is right in moral aspect, since nothing guys have done violates GPL.
you dont like it - dont use it. you arent obligated.
I used the word "IF" for a reason. I am trying to be rational about this. Is it reasonable to fork a framework addon and expect all its plugins to be forever backward compatible? I'm not saying that this is going to happen for all FuBar-2.0 plugins but it might happen to some. Realistically would I be surprised *if* fuBar-3.0 was not backward compatible with fuBar-2.0? No. Would I be surprised *if* there were new features in the fuBar-3.0 library that are not in fuBar-2.0 that authors want to use in future plugins? No. Would I be surprised *if* authors chose to stay current with the official FuBar release at the expense of FuBar2 and FuBarAce users? No. Forking the FuBar framework shouldn't limit Ckk's choice to move the FuBar framework forward.
It seems like it stands to reason that by choosing to create a non-sanctioned fork of FuBar you are choosing to maintain forward compatibility with the official FuBar framework aren't you? How would it be FuBar3's fault if new features don't work in FuBar2 or FuBarAce? It seems like what you want to do is create a snapshot in time where all things FuBar2 are frozen and unchanged. You can get this by tagging the old addons or downloading them from wowinterface.com can't you? Isn't that the choice you are wanting? It just won't be available with WAU that pulls directly from the trunk. Maybe you could add a feature to WAU to allow users to pull from branches or tags? The bottom line is that noone was forcing you to change in the first place. Once you saw that FuBar3 hit the trunk you could have easily gone back to FuBar2 and did that thing that protected your folder from bring detected by WAU. Since you dont like it, don't upgrade. But by forking it, you should inherit the baggage of that choice. Ckk shouldn't be shackled by someone refusing to move forward with him.
We're talking about major apps here like ora, bigwigs, and a whole slew of others, using fubar as a base interface... and they're not going to be rocked. While the idealist says that frameworks don't matter, the reality is that today, we end up loading doubles of a very great deal of the nonframework libraries. A lot of us care about that and don't want it.
Until these major addons have been moved away from fubar, there'll be a fubar2 kept alive. Simple as. Had it been me, I wouldn't have been in such a rush to port fubar to rock. (Then again I wouldn't have sat down and pieced together my very own framework to use for my own mods to begin with so maybe that's an irrelevant opinion.)
You make a good point about major addon support for fubar-2.0 and it really would be silly if something in FuBar-3.0 broke those. Ckk seems to be a pretty smart guy so he probably realizes this. Those other major addons shouldn't ever have to be "rocked" if those authors dont want to. Then again hey maybe someone will port those major addons to Rock right in the trunk too! That would solve the duplicate libraries issues for you. Or maybe we'll get to that state of framework agnostic libraries afterall and noone will be impacted by duplicate non-framework libs.