1) All author work done in branches only, trunk is automated, overwrites any author changes, trunk autofills with only projects tagged for release (requires annoying reconfiguration hassles).
2) Changes to WAU
updateflag = 0
updates = 0
if updateflag == 0 then
updateflag = 1
updates = updates + 1
updatefiles()
else
error("Don't be an inconsiderate a**. You've already tried updating " + updates + " times today.")
updates = updates + 1
end
I think the two main points here are, we need to get users out of trunk, by providing "stable betas" somehow, and we need to break them of the "constantly updating everything" habit by providing true releases. Users should only need to obsessively update addons that are in progress. Once an addon is stable and has all it's features it should move to WoWI, and bugfixes should go there as needed. Ace should provide betas, not alphas, and probably not releases... that is if we don't want to compete with WoWI directly there... but I think that ideal's long dead.
Or better yet, get alpha code out of the trunk and onto developer branches. That way the updater software doesn't have to change at all and you'd naturally put end-users on an update diet because there would be less frequent updates available on the trunk.
And yeah, it's definitely reasonable that the trunk have beta stuff (let developers use tagging for identifying release versions to ship to sites like WOWI), just not drycoded shoot-from-the-hip checkins - especially in libraries used by dozens of addons.
There is a difference, but it's a pedantic/academic one at this point since everyone is pulling down the same versions
Yeah,
from the same distribution point
yeah,
using the same tools.
no! The masses use WAU, and I'd say for the most part that anyone who uses SVN is a more advanced user, which makes them more likely to be someone who wants to test up-to-the minute code.
This is a very important distinction, because you can change the point where files.wowace.com is generated from much more easily than you can change the url on people's svn working copies.
Why do we keep going around and around, the system works. Don't go and break it.
Just change the rules about what gets zipped, and make it accessable via another name, and leave files.wowace.com as it is. We have had mirrors of the files site, just make a mirror with some alternate rules, you can have infinately many of them.
For those that don't know - WAU supports the command line SVN client if you have it installed - this includes off site repositories, and distributing your addon with its .svn folder from a primary release site is enough for WAU to auto-update it from an non-wowace svn.
For those that don't know - WAU supports the command line SVN client if you have it installed - this includes off site repositories, and distributing your addon with its .svn folder from a primary release site is enough for WAU to auto-update it from an non-wowace svn.
wtf i didn't know that.... that opens up a whole slew of possibilities that ... in fact might solve some problems.
The main problem is that all the files.wowace.com/WAU stuff was added way after the svn without changing how SVN is used. But this only bacame a real problem with more and more users not knowing anything about addon development using WAU to update their addons.
The SVN is used as it should be by most developers: main development happens in trunk, testing funky stuff besides the main code that may not make it goes into branches as do PTR updates.
But WAU is currently using these WIP version as basis for shiping them to the end user.
It would be cool to have a tool allowing the following:
- downloading release versions as default
- ability to use trunk or specific branches on a per addon basis
- fallback to trunk (but marked with a warning) if no release exists
This would require to reorganize the way the zips are created and some work by the devs but would imho present a clean solution.
One year ago, when i discovered wowace, site was entirely dedicated to addon development.
There were no "distribution methods" like wau or /files.
Testers had to manually download addons, update the libs, check via CIA etc ...
That was terribly annoying, but maybe better because we all knew (or almost all ...) what we did.
When a problem occured, we knew how to get an older working revision, we all came to check forums and help ...
Wowace.com was a communiyu site dedicated to addon development.
Stable releases were uploaded on curse/wowi.
Then, maybe some authors became really lazy, and no longer updated mods on websites.
The first auto-update scripts appeared, and were shared outside the wowace domain.
So what happened?
Hundreds, thousands of peeps that dont care about addon development and testing eat the bandwith.
And now they complaint about unstable addons?
What to do??
Lets go back older way, please ...
.Restrict wau use to registered users, or stop supporting it.
.Force developers to tag their addons, and have wau and /files use the tags branch.
.Force developers to upload their addons on wowI or Curse, it can be easy for some of you to create some "auto-update" scripts for these websites.
.If this can be done, svn access can be totally restricted to registered/authentified users.
Sometimes, the things need to be done some hard way ...
There are people behind wowace that give all of us more than time ...
Thanks, really, to everybody that puts money in wowace.com.
All devss give time for their addons, i thank you all, but just also thank one million time Kaelten, as he is who i think pays for the wowace hosting.
Yeah,yeah,no! The masses use WAU, and I'd say for the most part that anyone who uses SVN is a more advanced user, which makes them more likely to be someone who wants to test up-to-the minute code.
That's where I'm not seeing eye-to-eye with a couple of you: Right now, since everything really happens on the trunk, and everything points there, I really, really, really, really, really doubt that anyone but developers are regularly using the SVN directly. Testers are almost certainly using tools like WAU to pull down the latest development versions (because for 95% of WowAce addons that just happens to be the latest trunk version).
(btw, zomg Nymbia wher have you been?!)
Quote from sylvanaar »
That wont work
Agreed. The community has evolved into what it is now, and it's not bad. Putting our fingers in our ears and pretending nothing has changed would be highly damaging to the network of communication between developers, testers and end-users that has developed on this site. Please, let's move forward not back! Think about the whole picture of what makes WowAce a cool community as it is today and not just as it was intended to be in the beginning, and embrace those things instead of running in fear.[/soapbox]
to quote a known personality here "Lets be Practical." everyone here seems to have sugestions on how THEY thing it will get better, even i have one or two. But that's not the point really - the point becomes "What is Realisitc and Practical that will SOLVE the most important and most PROBLEMS".
Problem: the Current system of "Trunk -> Files -> WAU ->> MAsses" when authors have it in their head to do major work in the trunk is a bad idea.
Problem: Forcing the "heard of cats" that we call the Dev side of wowace to do anything is impractical.
Problem: Changing anything will require the Administrative staff to adjust the site and the site mechanics, this carries with it that WoWAce Admin is not a job but a hobby - time constraints of IRL apply.
Problem: Authors & Projects Must always have full control over thier distribution source. this protects it from being broken by translators and others doing "Bug Fixes"
--if you have any other things to add to the list of problems feel free to. it's better to identify the problem and present Realistic and Practical Solution to the admin than crying like kidds that had their toys taken away or broken.
Well, it really doesn't sound hard to me to modify the files zipping script. We can introduce a new folder property, lets call it "zip:path". Addon authors can add this property to their addon folder on /trunk for the zipscript to check. If it finds the property, it uses the path specified to zip instead of the version on /trunk.
This would mean it is easy for addon authors to transit to tagging stable releases and then adding the zip:path to point to that, without affecting the way it currently works. Authors aren't forced to use it, but can be encouraged to do so.
The best solutions are usually elegant and simple.
The svn repository will be reorganized. Each addon will have its own separate repository. In each repository there will be standardized locations for tagging beta and release versions. Tools will be written to make managing the repositories and the releases as painless as possible.
The files script will be updated for the new structure of the svn repositories and will generate zips for the release and beta tagged versions.
A lot of thought and discussion has gone into this already but there's still a lot of planning and work involved in making sure this happens and happens smoothly. Hopefully Kaelten will be able to share more details soon.
i think alot of us have been waiting for just that, i have atleast ...regardless what the plan is. Just something to be said from the Site Admin that something is in the works.
The svn repository will be reorganized. Each addon will have its own separate repository. In each repository there will be standardized locations for tagging beta and release versions. Tools will be written to make managing the repositories and the releases as painless as possible.
The files script will be updated for the new structure of the svn repositories and will generate zips for the release and beta tagged versions.
As a new(ish) developer here, I've not felt a lot of the pain that others have. I just wanted to say that I *heart* this plan and have no problems at all changing the way I work so that beta and stable versions of my mod are easy for the automated scripts and downloaders to find.
As someone who has designed and built build and distribution systems before, I know how nasty all the tiny little details are to get right. If you need a guinea pig to try this out on, I'm more than happy to lend a hand.
1) All author work done in branches only, trunk is automated, overwrites any author changes, trunk autofills with only projects tagged for release (requires annoying reconfiguration hassles).
2) Changes to WAU
Or better yet, get alpha code out of the trunk and onto developer branches. That way the updater software doesn't have to change at all and you'd naturally put end-users on an update diet because there would be less frequent updates available on the trunk.
And yeah, it's definitely reasonable that the trunk have beta stuff (let developers use tagging for identifying release versions to ship to sites like WOWI), just not drycoded shoot-from-the-hip checkins - especially in libraries used by dozens of addons.
Yeah,
yeah,
no! The masses use WAU, and I'd say for the most part that anyone who uses SVN is a more advanced user, which makes them more likely to be someone who wants to test up-to-the minute code.
This is a very important distinction, because you can change the point where files.wowace.com is generated from much more easily than you can change the url on people's svn working copies.
Just change the rules about what gets zipped, and make it accessable via another name, and leave files.wowace.com as it is. We have had mirrors of the files site, just make a mirror with some alternate rules, you can have infinately many of them.
For those that don't know - WAU supports the command line SVN client if you have it installed - this includes off site repositories, and distributing your addon with its .svn folder from a primary release site is enough for WAU to auto-update it from an non-wowace svn.
wtf i didn't know that.... that opens up a whole slew of possibilities that ... in fact might solve some problems.
The SVN is used as it should be by most developers: main development happens in trunk, testing funky stuff besides the main code that may not make it goes into branches as do PTR updates.
But WAU is currently using these WIP version as basis for shiping them to the end user.
It would be cool to have a tool allowing the following:
- downloading release versions as default
- ability to use trunk or specific branches on a per addon basis
- fallback to trunk (but marked with a warning) if no release exists
This would require to reorganize the way the zips are created and some work by the devs but would imho present a clean solution.
For example, create beta.xml
Reference in-development code, or set flags, include test harnesses, and display all that beta spam.
Then have the script empty the contents of beta.xml on the stable feed.
Its not WAU its the server script that decides what gets downloaded.
One year ago, when i discovered wowace, site was entirely dedicated to addon development.
There were no "distribution methods" like wau or /files.
Testers had to manually download addons, update the libs, check via CIA etc ...
That was terribly annoying, but maybe better because we all knew (or almost all ...) what we did.
When a problem occured, we knew how to get an older working revision, we all came to check forums and help ...
Wowace.com was a communiyu site dedicated to addon development.
Stable releases were uploaded on curse/wowi.
Then, maybe some authors became really lazy, and no longer updated mods on websites.
The first auto-update scripts appeared, and were shared outside the wowace domain.
So what happened?
Hundreds, thousands of peeps that dont care about addon development and testing eat the bandwith.
And now they complaint about unstable addons?
What to do??
Lets go back older way, please ...
.Restrict wau use to registered users, or stop supporting it.
.Force developers to tag their addons, and have wau and /files use the tags branch.
.Force developers to upload their addons on wowI or Curse, it can be easy for some of you to create some "auto-update" scripts for these websites.
.If this can be done, svn access can be totally restricted to registered/authentified users.
Sometimes, the things need to be done some hard way ...
There are people behind wowace that give all of us more than time ...
Thanks, really, to everybody that puts money in wowace.com.
All devss give time for their addons, i thank you all, but just also thank one million time Kaelten, as he is who i think pays for the wowace hosting.
That wont work
That's where I'm not seeing eye-to-eye with a couple of you: Right now, since everything really happens on the trunk, and everything points there, I really, really, really, really, really doubt that anyone but developers are regularly using the SVN directly. Testers are almost certainly using tools like WAU to pull down the latest development versions (because for 95% of WowAce addons that just happens to be the latest trunk version).
(btw, zomg Nymbia wher have you been?!)
Agreed. The community has evolved into what it is now, and it's not bad. Putting our fingers in our ears and pretending nothing has changed would be highly damaging to the network of communication between developers, testers and end-users that has developed on this site. Please, let's move forward not back! Think about the whole picture of what makes WowAce a cool community as it is today and not just as it was intended to be in the beginning, and embrace those things instead of running in fear.[/soapbox]
to quote a known personality here "Lets be Practical." everyone here seems to have sugestions on how THEY thing it will get better, even i have one or two. But that's not the point really - the point becomes "What is Realisitc and Practical that will SOLVE the most important and most PROBLEMS".
Problem: the Current system of "Trunk -> Files -> WAU ->> MAsses" when authors have it in their head to do major work in the trunk is a bad idea.
Problem: Forcing the "heard of cats" that we call the Dev side of wowace to do anything is impractical.
Problem: Changing anything will require the Administrative staff to adjust the site and the site mechanics, this carries with it that WoWAce Admin is not a job but a hobby - time constraints of IRL apply.
Problem: Authors & Projects Must always have full control over thier distribution source. this protects it from being broken by translators and others doing "Bug Fixes"
--if you have any other things to add to the list of problems feel free to. it's better to identify the problem and present Realistic and Practical Solution to the admin than crying like kidds that had their toys taken away or broken.
This would mean it is easy for addon authors to transit to tagging stable releases and then adding the zip:path to point to that, without affecting the way it currently works. Authors aren't forced to use it, but can be encouraged to do so.
The best solutions are usually elegant and simple.
There is a plan.
The svn repository will be reorganized. Each addon will have its own separate repository. In each repository there will be standardized locations for tagging beta and release versions. Tools will be written to make managing the repositories and the releases as painless as possible.
The files script will be updated for the new structure of the svn repositories and will generate zips for the release and beta tagged versions.
A lot of thought and discussion has gone into this already but there's still a lot of planning and work involved in making sure this happens and happens smoothly. Hopefully Kaelten will be able to share more details soon.
<Administrator>
i think alot of us have been waiting for just that, i have atleast ...regardless what the plan is. Just something to be said from the Site Admin that something is in the works.
As a new(ish) developer here, I've not felt a lot of the pain that others have. I just wanted to say that I *heart* this plan and have no problems at all changing the way I work so that beta and stable versions of my mod are easy for the automated scripts and downloaders to find.
As someone who has designed and built build and distribution systems before, I know how nasty all the tiny little details are to get right. If you need a guinea pig to try this out on, I'm more than happy to lend a hand.
Thanks for sharing what details you can. It sounds like you guys are on the right path to a good solution.