zcy
/
svgedit
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
svgedit/archive/from-old-wiki/DevelopmentProcess.md

61 lines
4.3 KiB
Markdown
Raw Normal View History

- Security fix: 'extPath', 'imgPath', 'extIconsPath', 'canvgPath', 'langPath', 'jGraduatePath', and 'jspdfPath' were not being prevented - Breaking change: Rename "svgutils.js" to "utilities.js" (make in conformity with JSDoc module naming convention) - Breaking change: Rename "svgedit.js" to "namespaces.js" (to make clear purpose and avoid confusing with editor) - Breaking change: Rename "jquery-svg.js" to "jQuery.attr.js" - Breaking change: Rename "jquery.contextMenu.js" to "jQuery.contextMenu.js" - Breaking change: Rename "jquery.jpicker.js" to "jQuery.jPicker.js" - Breaking change: Rename "JQuerySpinBtn.css" to "jQuery.SpinButton.css" - Breaking change: Rename "JQuerySpinBtn.js" to "jQuery.SpinButton.js" (to have file name more closely reflect name) - Breaking change: Rename "jquery.svgicons.js" to "jQuery.svgIcons.js" - Breaking change: Rename "jquery.jgraduate.js" to "jQuery.jGraduate.js" - Breaking change: Rename "pathseg.js" to "svgpathseg.js" (as it is a poyfill of SVGPathSeg) - Breaking change: Rename `addSvgElementFromJson()` to `addSVGElementFromJson` for consistency - Breaking change: Rename `changeSvgContent()` to `changeSVGContent()` for consistency - Breaking change: Have `exportPDF` resolve with `output` and `outputType` rather than `dataurlstring` (as type may vary) - Breaking change: Rename `extensions/mathjax/MathJax.js` to `extensions/mathjax/MathJax.min.js` - Breaking change: Avoid recent change to have editor ready callbacks return Promises (we're not using and advantageous to keep sequential) - Breaking change: Avoid recent addition of locale-side function in ext-imagelib for l10n - Breaking change: Change name of ext-arrows.js from `Arrows` to `arrows` for sake of file path (not localized anyways). - Breaking change: Change `addlangData` extension event to `addLangData` for consistency with method name - Breaking change: Have `readLang` return lang and data but do not call `setLang` - Fix: Have general locales load first so extensions may use - Fix: Provide `importLocale` to extensions `init` so it may delay adding of the extension until locale data loaded - Fix: Ensure call to `rasterExport` without `imgType` properly sets MIME type to PNG - Fix: Wrong name for moinsave - Update: Update WebAppFind per new API changes - Enhancement: Make `setStrings` public on editor for late setting (used by `ext-shapes.js`) - Enhancement: Add `extensions_added` event - Enhancement: Add `message` event (Relay messages including those which have been been received prior to extension load) - Enhancement: Allow SVGEdit to work out of the box--avoid need for copying sample config file. Should also help with Github-based file servers - Enhancement: Allow avoiding "name" in extension export (just extract out of file name) - Enhancement: Add stack blur to canvg by default (and refactoring it) - Enhancement: Return `Promise` for `embedImage` (as with some other loading methods) - Enhancement: Supply `importLocale` to `langReady` to facilitate extension locale loading - Enhancement: Recover if an extension fails to load (just log and otherwise ignore) - Enhancement: More i18n of extensions (also fixed issue with some console warnings about missing locale strings); i18nize Hello World too - Enhancement: Allowing importing of locales within `addLangData` - npm: Update devDeps - Docs: Migrate copies of all old wiki pages to docs/from-old-wiki folder; intended for a possible move to Markdown, so raw HTML (with formatting) was not preserved, though named links had their absolute URL links preserved - Docs: Begin deleting `SvgCanvas.md` as ensuring jsdoc has replacements - Docs: Add Edtior doc file for help to general users - Docs: Clarify/simplify install instructions - npm/Docs (JSDoc): Add script to check for overly generic types - Docs (JSDoc): For config/prefs and extension creating, link to tutorials (moved tutorials to own directory to avoid recursion problems by jsdoc) - Docs (JSDoc): Add modules (upper case for usual main entrance files or regular names) - Docs (JSDoc): Fill out missing areas; indicate return of `undefined`; consistency with `@returns` - Docs (JSDoc): Add our own layout template to support overflow - Docs (JSDoc): Use cleverLinks and disallow unknown tags - Docs (JSDoc): Insist on "pedantic" flag; put output directory in config - Docs (JSDoc): Use more precise Integer/Float over number, the specific type of array/function/object - Docs (JSDoc): Use `@throws`, `@enum`, `@event`/`@fires`/`@listens` - Docs: Generally update/improve docs (fixes #92) - Docs: Update links to `latest` path (Avoid needing to update such references upon each release) - Docs: 80 chars max - Refactoring: Drop code for extension as function (already requiring export to be an object) - Refactoring: Object destructuring, `Object.entries`, Object shorthand, array extras, more camelCase variable names - Refactoring: Add a `Command` base class - Refactoring: Simplify svgicons `callback` ready detection - Refactoring: Put `let` or `const` closer to scope - Refactoring: Remove unneeded `delimiter` from regex escaping utility - Refactoring: Clearer variable names - Refactoring: Use (non-deprecated) Event constructors - Testing: Use new Sinon
2018-06-06 07:26:20 +00:00
If you use SVG-edit, add to your Ohloh.net stacks: <wiki:gadget url="http://www.ohloh.net/p/325148/widgets/project_users.xml" height="100" border="0"/>
The Development Phases of a Release
NOTE: The duration of each of the phases below has not been defined at this time.
Pre-Alpha
During this phase, the trunk is completely open to contributions: new features, bug fixes, radical architectural changes. In this phase, the scope of the release will be locked down (features will be decided upon, new features will be voted and accepted for release targeting).
The trunk spends most of its lifetime in Pre-Alpha mode.
Alpha
During this phase, the majority of the features have been implemented on the trunk. Some minor features may still not be implemented yet. Portions of major features may be in a rough state during the Alpha phase.
No new features will be considered for the release, the scope is locked down.
Beta
During this phase, all feature work has been complete. The release has now gone into bug fix mode. Only fixes deemed critical to the release will be considered for check-in to the trunk.
Release
During this phase, the trunk will be branched to svn/branches/X.X (where X.X is the release number) and the following steps need to be performed:
Update the HTML to reference the aggregated minified JS file, svgedit.compiled.js (switch HTML comments)
Update the HTML to point to the Google CDN version of jQuery (switch HTML comments)
Change the version stored at the top of the Makefile
Run the Makefile, which does the following automatically
JS files will be minified on the branch
all files will be packaged up as a downloadable zip file
the Firefox extension will be packaged into an xpi file
the Opera widget will be packaged into a wgt file
[Opera Widgets are being phased out](http://my.opera.com/addons/blog/2012/04/24/sunsetting-unite-and-widgets)
Commit the now built minified JS file, svgedit.compiled.js
Project owner: ~~upload the zip, xpi and wgt files to the Google Code download section~~ (Commit the packaged files and/or add to Google Drive since new project downloads [now disabled](http://google-opensource.blogspot.hk/2013/05/a-change-to-google-code-download-service.html)?)
update the stable branch to refer to the new release branch via: $ svn delete -m "Removing old stable branch" https://svg-edit.googlecode.com/svn/branches/stable $ svn copy https://svg-edit.googlecode.com/svn/branches/2.3 https://svg-edit.googlecode.com/svn/branches/stable -m "Pointing stable branch to 2.3 branch"
A project owner should move the old version information from [Project home](https://code.google.com/p/svg-edit/) page to the VersionHistory page and move any information on the new release from the Roadmap to the [Project home](https://code.google.com/p/svg-edit/).
Update the Roadmap to refer to the next planned release (and keep updated with any new features added to trunk).
At this point, the trunk is now opened up again and enters Pre-Alpha phase for the next release.
If bugs are encountered with a released version, those fixes must be merged to both the release branch and the trunk (as well as to the "stable" branch if the bug is for the stable version).
Creating a Branch
For big experimental features, you may want to branch the repository to separate your work from the trunk. A branch in SVN is just a copy:
svn copy https://svg-edit.googlecode.com/svn/trunk/ https://svg-edit.googlecode.com/svn/branches/rotate-selector -m "Making a branch for..."
This will create the branch on the server. Then you can check it out as a working copy:
svn co https://svg-edit.googlecode.com/svn/branches/rotate-selector/ svg-edit-rotater
Then hack away in the 'svg-edit-rotater' folder and freely check in your changes (these will only be updating the rotate-selector branch in the repository. You can share your changes, have them reviewed, etc.
Once your happy with the branch, you can merge it in.
Rolling Back a Bad Commit
Let's say you accidentally committed your change when you didn't mean to as [revision 2075](https://code.google.com/p/svg-edit/source/detail?r=2075).
svn merge -r2075:2074 . svn ci -m "Rollback bad revision 2075"
TODO: instructions on automatically merging back to trunk
TODO: instructions for keeping up to date in the branch (i.e. merging from trunk to branch)