Ok, new proposal: Whenever you make a change that does any of these:
- Breaks backwards compatibility with existing user state (e.g. db
versions etc)
- Changes type of options
- Changes semantics of options
- Removes existing options
you should include a description of the change
Hi,
On 18/12/14 17:18, Wout Mertens wrote:
As a summary answer to all the answers, I think we should adopt a change log
as
described at http://keepachangelog.com/
We already have a place to document breaking changes, namely the NixOS release
notes in nixos/doc/manual/release-notes. I'm not
On Fri Dec 19 2014 at 3:02:34 PM Eelco Dolstra eelco.dols...@logicblox.com
wrote:
On 18/12/14 17:18, Wout Mertens wrote:
As a summary answer to all the answers, I think we should adopt a change
log as
described at http://keepachangelog.com/
We already have a place to document breaking
Hi,
On 19/12/14 15:10, Wout Mertens wrote:
We already have a place to document breaking changes, namely the NixOS
release
notes in nixos/doc/manual/release-__notes. I'm not in favour of having
multiple,
out-of-sync locations to keep this info.
Right, but those are not
Maybe we can think of a way to single-source (as in port the source changes
into two outputs, the .md file and the release notes)?
I'll be happy to help if I can :-)
On 19 Dec 2014, at 15:15, Eelco Dolstra eelco.dols...@logicblox.com wrote:
Hi,
On 19/12/14 15:10, Wout Mertens wrote:
stewart, the breaking changes are configuration definitions for the
unstable master branch, those can change I hope :)
On Fri Dec 19 2014 at 3:44:19 PM stewart mackenzie setor...@gmail.com
wrote:
This might sound a bit off-base, but could we please consider not
introducing feature breaking
Mikey, well given Eelco's comment it seems best to generate a CHANGELOG.md
from the XML file, but then I wonder if we should have one at all (apart
from the nice location).
The goals would be:
- Allow programmatic extraction of important changes between the current
nixos system and the one
Ah indeed thank you for the correction. Though my suggestion is to
adopt C4 in its entirety. There would be no unstable master branch. At
all times there is only one branch, that being master, and the stable
APIs as part of this master branch remain stable, to be depricated and
eventually made
Given that NixOS evolves rapidly compared to Rust (as a language), it's
going to be really hard to achieve that (without slowing down development
by orders of magnitude).
Note that API in NixOS is not defined, but if you're looking at it as NixOS
modules and packages, we're changing the API
As a summary answer to all the answers, I think we should adopt a change
log as described at http://keepachangelog.com/
Why?
- It's an attempt at a standard with features that make it somewhat
machine-parseable (we could write a test for it)
- It's MarkDown format so human-readable and
Great idea. A human readable changelog should mean less repetitive spam,
because people will know about breaking changes as they happen.
Aloha,
RK.
On Fri, Dec 19, 2014 at 2:18 AM, Wout Mertens wout.mert...@gmail.com
wrote:
As a summary answer to all the answers, I think we should adopt a
That looks good.
Would this just be published on the repo or on the site?
Are you planning to do the gentoo /news directory? I would prefer that
the changelog isn't actually in the OS itself. Or if it is, then maybe
an option in Nix that specifies whether to get the latest changelog or not.
Would it be nice if we kept a file with breaking changes?
That way, nixos-rebuild should be able to list the breaking changes between
the current version of the channel and the last time the system was built.
We'd also have the full list of breakage for release notes.
Thoughts? What would such
One thing I really like is Gentoo's news feature - which seems to be
discussed in detail at http://wiki.gentoo.org/wiki/GLEP:42. Maybe something
like that is what you're envisioning?
-- ocharles
On Wed, Dec 17, 2014 at 1:27 PM, Wout Mertens wout.mert...@gmail.com
wrote:
Would it be nice if we
Nice though it seems a bit complex. Not sure if it's over-engineered or
just what's needed.
Also interesting:
*There have been complaints regarding the comprehensibility of some
upgrade notices and news items in the past. This is understandable — not
every Gentoo developer speaks English as a
On 12/17/2014 01:55 PM, Wout Mertens wrote:
Nice though it seems a bit complex. Not sure if it's over-engineered or
just what's needed.
Also interesting:
*There have been complaints regarding the comprehensibility of some
upgrade notices and news items in the past. This is understandable —
16 matches
Mail list logo
