path: root/docs/_locale/_pot/development.pot

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2009-2015, Marcel Hellkamp
# This file is distributed under the same license as the Bottle package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Bottle 0.13-dev\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-01-22 16:45-0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../../development.rst:2
# 2cc9e7218b1849fe8209f6035fd39f16
msgid "Developer Notes"
msgstr ""

#: ../../development.rst:4
# 7c9b846dd8324411b1a8df1e6835f159
msgid "This document is intended for developers and package maintainers interested in the bottle development and release workflow. If you want to contribute, you are just right!"
msgstr ""

#: ../../development.rst:8
# 42938cfc6b2a475eaf997bb701f298a4
msgid "Get involved"
msgstr ""

#: ../../development.rst:10
# 841d96a6988c4a3f967230d6650180fe
msgid "There are several ways to join the community and stay up to date. Here are some of them:"
msgstr ""

#: ../../development.rst:12
# 14fb93b497c84a43ac63736d40ff98a2
msgid "**Mailing list**: Join our mailing list by sending an email to `bottlepy+subscribe@googlegroups.com <mailto:bottlepy+subscribe@googlegroups.com>`_ (no google account required)."
msgstr ""

#: ../../development.rst:13
# 17768f33453c4709ab847f43051152d9
msgid "**Twitter**: `Follow us on Twitter <https://twitter.com/bottlepy>`_ or search for the `#bottlepy <https://twitter.com/#!/search/%23bottlepy>`_ tag."
msgstr ""

#: ../../development.rst:14
# a3b2221cb81048ea92a92ea498cd9f6c
msgid "**IRC**: Join `#bottlepy on irc.freenode.net <irc://irc.freenode.net/bottlepy>`_ or use the `web chat interface <http://webchat.freenode.net/?channels=bottlepy>`_."
msgstr ""

#: ../../development.rst:15
# aaf45044eec34c9f8bcd9dbc017ca372
msgid "**Google plus**: We sometimes `blog about Bottle, releases and technical stuff <https://plus.google.com/b/104025895326575643538/104025895326575643538/posts>`_ on our Google+ page."
msgstr ""

#: ../../development.rst:19
# e0bc2999fcb6454fac3b6603e04bd6ea
msgid "Get the Sources"
msgstr ""

#: ../../development.rst:21
# b54143d35e8e4ee59a6402030f6e3c09
msgid "The bottle `development repository <https://github.com/bottlepy/bottle>`_ and the `issue tracker <https://github.com/bottlepy/bottle/issues>`_ are both hosted at `github <https://github.com/bottlepy/bottle>`_. If you plan to contribute, it is a good idea to create an account there and fork the main repository. This way your changes and ideas are visible to other developers and can be discussed openly. Even without an account, you can clone the repository or just download the latest development version as a source archive."
msgstr ""

#: ../../development.rst:23
# bd36c66d54d84d2bad6b14d828f7f35b
msgid "**git:** ``git clone git://github.com/bottlepy/bottle.git``"
msgstr ""

#: ../../development.rst:24
# ad2d4b5181804d05816f7beeaa1a8e2d
msgid "**git/https:** ``git clone https://github.com/bottlepy/bottle.git``"
msgstr ""

#: ../../development.rst:25
# 34432078033145b7b44be8e831ea02c6
msgid "**Download:** Development branch as `tar archive <http://github.com/bottlepy/bottle/tarball/master>`_ or `zip file <http://github.com/bottlepy/bottle/zipball/master>`_."
msgstr ""

#: ../../development.rst:29
# 721bca39cc4145d7b6e319178958e071
msgid "Releases and Updates"
msgstr ""

#: ../../development.rst:31
# 1f4cb83f0f2f421c9d070c2f3f1c7359
msgid "Bottle is released at irregular intervals and distributed through `PyPI <http://pypi.python.org/pypi/bottle>`_. Release candidates and bugfix-revisions of outdated releases are only available from the git repository mentioned above. Some Linux distributions may offer packages for outdated releases, though."
msgstr ""

#: ../../development.rst:33
# 50ff64742c50405781fe6dbf6232683c
msgid "The Bottle version number splits into three parts (**major.minor.revision**). These are *not* used to promote new features but to indicate important bug-fixes and/or API changes. Critical bugs are fixed in at least the two latest minor releases and announced in all available channels (mailinglist, twitter, github). Non-critical bugs or features are not guaranteed to be backported. This may change in the future, through."
msgstr ""

#: ../../development.rst:36
# 9858a522f4ab4d4183754187581fd709
msgid "Major Release (x.0)"
msgstr ""

#: ../../development.rst:36
# e9c8607f06f54e53ab612abefc1147fd
msgid "The major release number is increased on important milestones or updates that completely break backward compatibility. You probably have to work over your entire application to use a new release. These releases are very rare, through."
msgstr ""

#: ../../development.rst:39
# 524edfa62b264b9f99abcecc2412f21f
msgid "Minor Release (x.y)"
msgstr ""

#: ../../development.rst:39
# 1b73955fe41446548138ba823103e823
msgid "The minor release number is increased on updates that change the API or behaviour in some way. You might get some depreciation warnings any may have to tweak some configuration settings to restore the old behaviour, but in most cases these changes are designed to be backward compatible for at least one minor release. You should update to stay up do date, but don't have to. An exception is 0.8, which *will* break backward compatibility hard. (This is why 0.7 was skipped). Sorry about that."
msgstr ""

#: ../../development.rst:42
# 646f4932085742c6a24285f09390e3bf
msgid "Revision (x.y.z)"
msgstr ""

#: ../../development.rst:42
# 1845455d79da4cff9d8c1f9b1c7bf9d9
msgid "The revision number is increased on bug-fixes and other patches that do not change the API or behaviour. You can safely update without editing your application code. In fact, you really should as soon as possible, because important security fixes are released this way."
msgstr ""

#: ../../development.rst:46
# 624da48d84104aaa981b33c9c2f834a1
msgid "Pre-Release Versions"
msgstr ""

#: ../../development.rst:45
# 1a5fe70873d44ed2ad4948d21edc9b5b
msgid "Release candidates are marked by an ``rc`` in their revision number. These are API stable most of the time and open for testing, but not officially released yet. You should not use these for production."
msgstr ""

#: ../../development.rst:49
# 13e3f747aefa4f5798e1858e263d10a8
msgid "Repository Structure"
msgstr ""

#: ../../development.rst:51
# b6525e01476945bd8e82fcbc48889f22
msgid "The source repository is structured as follows:"
msgstr ""

#: ../../development.rst:54
# e57e8922c7cf4b0f964fd268be39f89e
msgid "``master`` branch"
msgstr ""

#: ../../development.rst:54
# 213d6b02a9d14d8dad6a30982dfb66e1
msgid "This is the integration, testing and development branch. All changes that are planned to be part of the next release are merged and tested here."
msgstr ""

#: ../../development.rst:57
# fb5cc64ac52d4b999d683174ddd1ccb1
msgid "``release-x.y`` branches"
msgstr ""

#: ../../development.rst:57
# b8d2a0e33e364b27a455b0442b5f04ff
msgid "As soon as the master branch is (almost) ready for a new release, it is branched into a new release branch. This \"release candidate\" is feature-frozen but may receive bug-fixes and last-minute changes until it is considered production ready and officially released. From that point on it is called a \"support branch\" and still receives bug-fixes, but only important ones. The revision number is increased on each push to these branches, so you can keep up with important changes."
msgstr ""

#: ../../development.rst:60
# 0e9b4bc11a924ee1a9bc903539a0403c
msgid "``bugfix_name-x.y`` branches"
msgstr ""

#: ../../development.rst:60
# f52ac3dfbfff46a49650110671b2769b
msgid "These branches are only temporary and used to develop and share non-trivial bug-fixes for existing releases. They are merged into the corresponding release branch and deleted soon after that."
msgstr ""

#: ../../development.rst:64
# 7ecbcf27e8c8487998098d3afd73a93f
msgid "Feature branches"
msgstr ""

#: ../../development.rst:63
# d1eaaac8479d41b88f755dd230fc2c4a
msgid "All other branches are feature branches. These are based on the master branch and only live as long as they are still active and not merged back into ``master``."
msgstr ""

#: ../../development.rst:67
# 8d9b8169f20641a98063660ab23470e4
msgid "What does this mean for a developer?"
msgstr ""

#: ../../development.rst:68
# 538a9a5bdf7e4f32b49a11d29aa4892d
msgid "If you want to add a feature, create a new branch from ``master``. If you want to fix a bug, branch ``release-x.y`` for each affected release. Please use a separate branch for each feature or bug to make integration as easy as possible. Thats all. There are git workflow examples at the bottom of this page."
msgstr ""

#: ../../development.rst:70
# 572d2e19c9754159b0e24560801024f7
msgid "Oh, and never ever change the release number. We'll do that on integration. You never know in which order we pull pending requests anyway :)"
msgstr ""

#: ../../development.rst:74
# 8301d59656534d29b500ccbab1056d1a
msgid "What does this mean for a maintainer ?"
msgstr ""

#: ../../development.rst:75
# d4a7251b886a45868e49e0d093add938
msgid "Watch the tags (and the mailing list) for bug-fixes and new releases. If you want to fetch a specific release from the git repository, trust the tags, not the branches. A branch may contain changes that are not released yet, but a tag marks the exact commit which changed the version number."
msgstr ""

#: ../../development.rst:79
# 53d4d451df534e0bbf71dd61908fb349
msgid "Submitting Patches"
msgstr ""

#: ../../development.rst:81
# 05bd2b5c4e6f4a4cbcb6121d6ed77a03
msgid "The best way to get your changes integrated into the main development branch is to fork the main repository at github, create a new feature-branch, apply your changes and send a pull-request. Further down this page is a small collection of git workflow examples that may guide you. Submitting git-compatible patches to the mailing list is fine too. In any case, please follow some basic rules:"
msgstr ""

#: ../../development.rst:83
# ad1eb0a3c3864ec78e817863de841712
msgid "**Documentation:** Tell us what your patch does. Comment your code. If you introduced a new feature, add to the documentation so others can learn about it."
msgstr ""

#: ../../development.rst:84
# 7c54347d39db45fdb902c07dca1f6000
msgid "**Test:** Write tests to prove that your code works as expected and does not break anything. If you fixed a bug, write at least one test-case that triggers the bug. Make sure that all tests pass before you submit a patch."
msgstr ""

#: ../../development.rst:85
# 785853b0757f4bc296e46957a67aefd8
msgid "**One patch at a time:** Only fix one bug or add one feature at a time. Design your patches so that they can be applyed as a whole. Keep your patches clean, small and focused."
msgstr ""

#: ../../development.rst:86
# a2ef11182a7f4ad09b8a92a9f519e4db
msgid "**Sync with upstream:** If the ``upstream/master`` branch changed while you were working on your patch, rebase or pull to make sure that your patch still applies without conflicts."
msgstr ""

#: ../../development.rst:90
# d36de942becb4ffd943e11620e7ef81b
msgid "Building the Documentation"
msgstr ""

#: ../../development.rst:92
# 5c8dc0f99ff242eaa6bd2fb44c6815a8
msgid "You need a recent version of Sphinx to build the documentation. The recommended way is to install :command:`virtualenv` using your distribution package repository and install sphinx manually to get an up-to-date version."
msgstr ""

#: ../../development.rst:123
# 0ffc9e13d6774d21ae816774b7b4ba64
msgid "GIT Workflow Examples"
msgstr ""

#: ../../development.rst:125
# 6167a9d9443a4e8cba7bb69b9afc50bd
msgid "The following examples assume that you have an (free) `github account <https://github.com>`_. This is not mandatory, but makes things a lot easier."
msgstr ""

#: ../../development.rst:127
# 823bd71b9b8a452f9a208d0dfc8ba549
msgid "First of all you need to create a fork (a personal clone) of the official repository. To do this, you simply click the \"fork\" button on the `bottle project page <https://github.com/bottlepy/bottle>`_. When the fork is done, you will be presented with a short introduction to your new repository."
msgstr ""

#: ../../development.rst:129
# 02a883ab14ac4cb7a61fc961d800f398
msgid "The fork you just created is hosted at github and read-able by everyone, but write-able only by you. Now you need to clone the fork locally to actually make changes to it. Make sure you use the private (read-write) URL and *not* the public (read-only) one::"
msgstr ""

#: ../../development.rst:133
# 712b388ae70841b58dc350d1b22a3768
msgid "Once the clone is complete your repository will have a remote named \"origin\" that points to your fork on github. Don’t let the name confuse you, this does not point to the original bottle repository, but to your own fork. To keep track of the official repository, add another remote named \"upstream\"::"
msgstr ""

#: ../../development.rst:139
# 93d470f357b44d1ab21c530b9577ced7
msgid "Note that \"upstream\" is a public clone URL, which is read-only. You cannot push changes directly to it. Instead, we will pull from your public repository. This is described later."
msgstr ""

#: ../../development.rst:142
# 4c2a34afcf4b49e6bd96a98222168f4a
msgid "Submit a Feature"
msgstr ""

#: ../../development.rst:143
# a88156c0452e440699e76d8f2758d82d
msgid "New features are developed in separate feature-branches to make integration easy. Because they are going to be integrated into the ``master`` branch, they must be based on ``upstream/master``. To create a new feature-branch, type the following::"
msgstr ""

#: ../../development.rst:147
# e8439780081347d8955ebfa2db5aa838
msgid "Now implement your feature, write tests, update the documentation, make sure that all tests pass and commit your changes::"
msgstr ""

#: ../../development.rst:151
# 776bea38590e4d9498ba0098aebb7d41
msgid "If the ``upstream/master`` branch changed in the meantime, there may be conflicts with your changes. To solve these, 'rebase' your feature-branch onto the top of the updated ``upstream/master`` branch::"
msgstr ""

#: ../../development.rst:156
# 9fcfca3d487f4139917c38721557f7fa
msgid "This is equivalent to undoing all your changes, updating your branch to the latest version and reapplying all your patches again. If you released your branch already (see next step), this is not an option because it rewrites your history. You can do a normal pull instead. Resolve any conflicts, run the tests again and commit."
msgstr ""

#: ../../development.rst:158
# 9a6057b7c044422c9f0985a966e09e15
msgid "Now you are almost ready to send a pull request. But first you need to make your feature-branch public by pushing it to your github fork::"
msgstr ""

#: ../../development.rst:162
# 86aa60a957a0409a9be48263d46fba74
msgid "After you’ve pushed your commit(s) you need to inform us about the new feature. One way is to send a pull-request using github. Another way would be to start a thread in the mailing-list, which is recommended. It allows other developers to see and discuss your patches and you get some feedback for free :)"
msgstr ""

#: ../../development.rst:164
# df95b00dab994494bd3bd061fa33e6a5
msgid "If we accept your patch, we will integrate it into the official development branch and make it part of the next release."
msgstr ""

#: ../../development.rst:167
# b5718869cf334a5cb7915c64e4c09f87
msgid "Fix a Bug"
msgstr ""

#: ../../development.rst:168
# ae1914c99ab34a01951228a5ac7541fe
msgid "The workflow for bug-fixes is very similar to the one for features, but there are some differences:"
msgstr ""

#: ../../development.rst:170
# bc2f65fe0f414bb083df1fa0a5da921d
msgid "Branch off of the affected release branches instead of just the development branch."
msgstr ""

#: ../../development.rst:171
# 9668ede23ccb437abcf841dcc7cfba8f
msgid "Write at least one test-case that triggers the bug."
msgstr ""

#: ../../development.rst:172
# 422540c701124a1488935c96497b8c28
msgid "Do this for each affected branch including ``upstream/master`` if it is affected. ``git cherry-pick`` may help you reducing repetitive work."
msgstr ""

#: ../../development.rst:173
# b530d5b33c6b45a2a34c570368c6e04f
msgid "Name your branch after the release it is based on to avoid confusion. Examples: ``my_bugfix-x.y`` or ``my_bugfix-dev``."
msgstr ""