/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/cycle.txt

  • Committer: Breezy landing bot
  • Author(s): Colin Watson
  • Date: 2020-11-16 21:47:08 UTC
  • mfrom: (7521.1.1 remove-lp-workaround)
  • Revision ID: breezy.the.bot@gmail.com-20201116214708-jos209mgxi41oy15
Remove breezy.git workaround for bazaar.launchpad.net.

Merged from https://code.launchpad.net/~cjwatson/brz/remove-lp-workaround/+merge/393710

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/cycle.txt
1
1
*********************
2
 
Bazaar Release Cycles
 
2
Breezy Release Cycles
3
3
*********************
4
4
 
5
 
:status: Current policy, as of 2010-10.
6
 
:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
 
5
:status: Current policy, as of 2017-11.
7
6
 
8
7
 
9
8
Our users want easy access to bug fixes without other changes to the
10
9
core product. They also want a Just Works experience across the full
11
 
Bazaar ecosystem. To deliver the first and enable the second, we're
 
10
Breezy ecosystem. To deliver the first and enable the second, we're
12
11
adopting some standard process patterns: a 6 monthly release cycle and a
13
12
stable series. These changes will also have other benefits, including
14
13
better availability of bug fixes in OS distributions, more freedom to
16
15
 
17
16
See also:
18
17
 
19
 
* `Bazaar Developer Document Catalog <index.html>`_
 
18
* `Breezy Developer Document Catalog <index.html>`_
20
19
 
21
20
* `Releasing Bazaar <releasing.html>`_ -- the process for actually making
22
21
  a release or release candidate.
25
24
The Process
26
25
************
27
26
 
28
 
Bazaar will make a major release every six months, which will be supported at
 
27
Breezy will make a major release every six months, which will be supported at
29
28
least until the time of the next major release and generally 18 months after
30
29
the first final release in a series.  During this support period, we'll make
31
30
incremental releases which fix bugs, but which do not change network or disk
193
192
Within a development series, the focus is on helping plugin authors keep
194
193
up to date by giving clear error messages when an interface is removed.
195
194
We will no longer focus on letting old plugin code work with new versions
196
 
of bzrlib, which is an elusive target in Python.
 
195
of breezy, which is an elusive target in Python.
197
196
 
198
197
This may mean that in cases where today a plugin would keep running but
199
198
give warnings, it will now fail altogether with an error.
200
199
 
201
 
In return we expect more freedom to change and cleanup bzrlib code without
 
200
In return we expect more freedom to change and cleanup breezy code without
202
201
needing to keep old code around, or write extra compatibility shims, or
203
202
have review turnarounds related to compatibility.  Some changes, such as
204
203
removing module-global variables, that are hard to do now, will be
205
204
possible to do safely.
206
205
 
207
 
Discussion of plugins here includes programs that import and use bzrlib
 
206
Discussion of plugins here includes programs that import and use breezy
208
207
but that aren't technically plugins.  The same approach, though the
209
208
technical considerations are different, should apply to other extensions
210
209
such as programs that use bzr through the shell interface.
251
250
 
252
251
This can be handled in various ways either at the OS packaging or the
253
252
Python level.  We don't propose to directly address it in the upstream
254
 
source.  (For example, we will not change the bzrlib library name from one
 
253
source.  (For example, we will not change the breezy library name from one
255
254
release to the next.)
256
255
 
257
256
The issue already exists with people who may want to use for example the