Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. clang-format (Andrei Pavel)
2. Re: Kea's database schema versioning in practice
(Richard J. Letts)
----------------------------------------------------------------------
Message: 1
Date: Fri, 9 Sep 2016 17:04:06 +0300
From: Andrei Pavel <[email protected]>
To: [email protected]
Subject: [kea-dev] clang-format
Message-ID:
<caensvgwrwzg+lk38mq5kwcshmup6k8o_5bpa2pgdt1mo9n6...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello ISC,
In an attempt to automatize code styling, we've been experimenting
with clang-format for the last month.
We've managed to come up with a style[1] that is consistent with Kea
guidelines[2] and the majority of the existing Kea code style.
We'd be happy to see it part of the official Kea repository after
you've experimented with it yourself and modified it as you see fit.
I'm sure you already know this, to use it - you save it in Kea's
source root directory and run clang-format --style=file <filename>.
Use -lines parameter if you want to partially format the file. Lots of
editors (e.g. vim, Eclipse, QtCreator, Atom) have plugins that already
support this via a keyboard shortcut which might be more convenient.
[1] https://gist.github.com/andreipavelQ/48670c206f0538c4116941ea567ff60d
[2] http://kea.isc.org/wiki/CodingGuidelines
--
Andrei
Qualitance
------------------------------
Message: 2
Date: Fri, 9 Sep 2016 15:19:48 +0000
From: "Richard J. Letts" <[email protected]>
To: Kea Dev List <[email protected]>
Subject: Re: [kea-dev] Kea's database schema versioning in practice
Message-ID:
<dm5pr08mb26339e105586db1c4f2ffb27c0...@dm5pr08mb2633.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: kea-dev [mailto:[email protected]] On Behalf Of Marcin
> Siodelski
> Sent: Friday, August 26, 2016 7:55 AM
> To: Kea Dev List <[email protected]>
> Subject: [kea-dev] Kea's database schema versioning in practice
>
> Hi All,
>
> I am soliciting feedback about the issue raised during review of Kea ticket
> http://kea.isc.org/ticket/4562.
>
> Kea is using switchable lease/host database backends. The database
> schemas constantly evolve as we add new features which use those
> backends. As an example, in Kea 1.1 release we're significantly expanding
> support for Host Reservations. We have added support for reserving DHCP
> options per host, reserving DHCPv4 message fields like next server, boot file
> name (for PXE boot) etc. In PostgreSQL we have created host reservations
> from scratch since Kea 1.0.
> Kea 1.1 will be released with MySQL schema version 5.0 and PostgreSQL
> schema version 3.0.
The schema versions should be the same at a release; having different version
numbers for different backends raises questions about compatibility that you
will have to waste time addressing.
> During the development of Kea 1.1 we made extensive changes to the
> schemas but these changes didn't all appear at once. ...
> If he took some later revision of
> Kea, he could observe that the schema number didn't change but the
> schemas were actually updated, and so on.
I don't think this was a good idea
> So the policies required seem to be:
>
> - Should we bump up schema versions and update schema upgrade scripts
> every time we commit the change to master?
Yes
Bump the minor version number throughout development as the schema changes, and
then bump to the major.0 on release
> - What does it mean a major change to a schema? In other words, in what
> cases we need to bump up major version number vs minor version number?
A release.
There may be no changes between 4.last and 5.0 but that is better than
developers being on some vague version in between and not knowing if they have
a schema issue or something else.
(was on vacation)
/RjL
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 30, Issue 5
**************************************
