| The text on this page should only be modified by subscribers to Audacity-devel mailing list.
To understand what this page is for and how it is used, please join that list or read the list archives on Sourceforge.
|Users who want to request new features for Audacity are very welcome to do so on our Feature Requests page. We also have several other pages where you can learn more about feature requests and planning.|
How Features Get Planned
Experience shows that a normal roadmap with dates and planned sequence of version numbers and what they will contain is completely out of the question for Audacity. We don't have a single person running the show. In any case the classic choice:
"Scope, Schedule, Quality - Pick Two"
applies to Audacity. Roadmaps that attempt to control all three are not realistic. Our current choices are to release often to a fixed date chosen in advance (Schedule). We also choose to focus on removing bugs (Quality).
You could argue that there isn't any roadmap for Audacity. Instead different team members may or may not argue here for their views as to how development should happen going forward.
The Release Schedule
- We released Audacity 1.3.10 Beta on 1st December 2009.
- We released Audacity 1.3.11 Beta on 18th January 2010.
- 1.3.12 released 1Mar10
- 1.3.13 released 6Apr11
- 1.3.14 released 8Dec11
- 2.0.0 released 13 March 2012
- 2.0.1 released 29 June 2012
- 2.0.2 released 24 August 2012
- 2.0.3 released 21 January 2013
- 2.0.4 released 06 September 2013
- 2.0.5 released 21 October 2013
- 2.0.6 released 29 September 2014
- 2.1.0 released 29 March 2015
- 2.1.1 released 16 July 2015
- 2.1.2 released 20 January 2016
Roadmap according to James
These are James Crook's views...
- Audacity head should be stable/releasable at nearly all times - and in particular should compile on all three platforms. Destabilising changes should be worked on and fixed in a branch first. It's changes outside our control such as being forced to upgrade to wx3 or arrival of Win10, or changes in Mac Sierra that can thwart that goal.
- Aim for relatively frequent releases. If new features aren't ready, we switch them off rather than delay while they are refined.
- Big new features should be in plug-ins. That makes it so much easier to keep Audacity stable. Cleanspeech, Karaoke and Timer record should become Audacity plug-ins.
- Option of context help in the preferences dialogs taken directly from the manual.
- Improvements to scrolling and zooming behaviour for close up work. Our code is fast enough to do an oscilloscope style display on P700+, but for that to work well some changes are needed in how we select audio and how we choose to scroll.
- I'd like to see discontinuous selections implemented. This would be a lot cleaner than 'labelled region' operations. It would also drive the code structure that fixes whitespace versus silence issues.
- Re-organisation of menus. These (in my opinion) have grown to be large and confusing. They are partly to blame for the save-export confusion in many users. Making the options under the menu items more powerful reduces the number of menu items we need. Discussion at Proposal Menu Reorganisation and related sub pages.
- Fix multi-tool mode so that it can drag clips. This got broken by the introduction of multi-clips making multi-tool mode much less useful.
- Enhancement to screenshot tool so as to screen-capture modal dialogs and menus for the manual.
- The over-due TrackPanel refactor. We need to make it easy for plug-ins to plug-in new track types.
Increasing Satisfaction in Participation
- Listen for and invite feedback from new contributors. For example the need for better internal documentation in the code was highlighted by both 2009 GSoC students.
- Get across to new contributors that this is a do-ocracy. In general the person who does the work on something decides how it should be.
- Help people increase their own productivity. Spot cases of people pulling in opposite directions early. Turn queries into FAQs. Turn e-mails into documentation. Turn tests into features. Turn closed bugs into development policies.
We need to look at these... What we do is up for discussion...
- Bug tracking - (mostly done) Bugs are now in Bugzilla, with search page at Bug Lists
- Translation infrastructure.
- Should we close down firstname.lastname@example.org and make people use the forum?
- Peter 16Feb12: +1 to this
- Gale 17Feb12: -1 (as it's my decision it has to stay open). There are many reasons against closing it, and not many reasons for. You can contact me privately or talk about it in the Forum if you want.
Roadmap according to Peter Sampson
- Revised menu structure from DarkAudacity
- Proposal Locking and/or Hiding Pan and Gain sliders - to avoid accidental unintended nudges
- Proposal Help button for Effects, Generators and Analyzers a proposal to provide help to users of effects, generators and analyzers
- Proposal Timer Record Improvements Phase-2 - access to the controls and timer changes while Timer Record is active (recording or waiting)
- Proposal Graphic indicator of optimum recording level on the waveform display improve the User Interface relating to the Metering and Monitoring functionality in Audacity
- Proposal Easy cfg Reset - frequently needed in Forum advice to users
- Proposal DC Offset removal and not Proposal DC Management - usabilty, encourages proper processing order
- Proposal: Improvements to Scrubbing - Phase-3
- Effects Categorization (31 votes) - now that Proposal Binding Effects to Hot-Keys is implemented
- The Multiproject Wormcan I strongly favour option 2: Single recorder/player mode