Apache AGE is licensed under Apache License, version 2.0

v0.1.0-alpha ✅
Release Date	2020 Q1
Release Notes	https://github.com/apache/incubator-age/releases/tag/v0.1.0
Key Improvements	Agtype to support all datatype requirements in Cypher queries Basic MATCH and CREATE clause support Expression support

v0.2.0-alpha ✅
Release Date	2020 Q2
Release Notes	https://github.com/apache/incubator-age/releases/tag/v0.2.0
Key Improvements	Extend Agtype to function better for SQL queries Scalar functions Advanced MATCH and CREATE clause support (except for VLE)

v0.3.0-incubating (official Apache incubator release) ✅
Release Date	2021-FEB-19
Release Notes	https://github.com/apache/incubator-age/releases/tag/v0.3.0.rc0-incubating
Key Improvements	Aggregation query support DELETE, SET, REMOVE, MERGE clause support Label Inheritance

v0.4.0-incubating (official Apache incubator release) ✅
Release Date	2021-MAY-03
Release Notes	https://github.com/apache/incubator-age/releases/tag/0.4.0
Key Improvements	Aggregation support (Auto Group By, more input types) Basic agtype parser for the NodeJS driver Graph visualization tool integration Support for stored procedures and PL/pgSQL

v0.5.0-incubating (official Apache incubator release) ✅
Release Date	2021-AUG-03
Release Notes	https://github.com/apache/incubator-age/releases/tag/v0.5.0
Key Improvements	Agtype's support for Hash Join for better performance Improved support for DELETE Support for CASE stetement and PostgreSQL EXPLAIN command ANTLR4 grammar file for JDBC, NodeJS drivers

v0.6.0-incubating (official Apache incubator release) ✅
Release Date	2021-DEC-01
Release Notes	https://github.com/apache/incubator-age/releases/tag/v0.6.0
Key Improvements	Partial openCypher VLE (Variable Length Edges) Set returning function Bug fixes

* PostgreSQL 12 support will be implemented in Q1 2022.

Docker images are available on Docker Hub and are based on the official PostgreSQL 11 Debian and Alpine images.

• AGE Debian Docker Image
• AGE Alpine Docker Image

Building AGE from source depends on the following Linux libraries (Ubuntu package names shown below): The build process will attempt to use the first path in the PATH environment variable when installing AGE. If the pg_config path if located there, run the following command in the source code directory of Apache AGE to build and install the extension. If the path to your Postgres installation is not in the PATH variable, add the path in the arguments: Since Apache AGE will be installed in the directory of the PostgreSQL installation, proper permissions on the directory are required. Run the following statements in psql to create and load age in PostgreSQL.

Connect to your containerized Postgres instance and then run the following commands: First you will need to create a graph: To execute Cypher queries, you will need to wrap them in the following syntax: For example, if we wanted to create a graph with 4 nodes, we could do something as shown below: Then we could query the graph with the following: Next, we could create a relationship between a couple of nodes: Next we can return the path we just created (results have been formatted for readability):

There are multiple ways you can contribute to the project. And help is always welcome! All details can be found on the contributing page. Keep reading for a quick overview! If you are interested in the project and looking for ways to help, consult the list of tasks in JIRA, or ask the mailing list. A great way to contribute to AGE is to help answer user questions on the mailing list or on StackOverflow. There are always many new AGE users; taking a few minutes to help answer a question is a very valuable community service.
Contributors should subscribe to this list and follow it to keep up to date on what's happening in AGE. Answering questions is an excellent and visible way to help the community, which also demonstrates your expertise. Changes to AGE source code are proposed, reviewed, and committed via Github pull requests (described in Developer Guidelines). Anyone can view and comment on active changes here. Reviewing others' changes is a good way to learn how the change process works and gain exposure to activity in various parts of the code. You can help by reviewing the changes and asking questions or pointing out issues as simple as typos or small issues of style. To propose a change to release documentation (that is, docs that appear here), edit the Markdown source files in AGE's doc/ directory on GitHub. Instructions for building the documentation can be found here. The process to propose a doc change is otherwise the same as the process for proposing code changes below. Ideally, bug reports are accompanied by a proposed code change to fix the bug. This isn't always possible, as those who discover a bug may not have the experience to fix it. A bug may be reported by creating a JIRA issue but without creating a pull request.
Bug reports are only useful, however, if they include enough information to understand, isolate and ideally reproduce the bug. Simply encountering an error does not mean a bug should be reported; search JIRA and inquire on the AGE user / dev mailing lists first. Unreproducible bugs, or simple error reports, may be closed.
The more context the reporter can give about a bug, the better, such as: how the bug was introduced, by which commit, etc. It assists the committers in the decision process on how far the bug fix should be backported, when the pull request is merged. The pull request to fix the bug should narrow down the problem to the root cause.
Data correctness/data loss bugs are very serious. Make sure the corresponding bug report JIRA issue is labeled as correctness or data-loss. Please send an email to dev@age.apache.org after submitting the bug report, to quickly draw attention to the issue.
Performance issues are classified as bugs. The pull request to fix a performance bug must provide a benchmark to prove the problem is indeed fixed. Most contributors can directly resolve JIRA issues. Use judgment in determining whether you are confident the issue should be resolved (although changes can be easily undone).
When resolving JIRA tickets, please observe the following conventions:

• Resolve as Fixed if there's a release or code commit that resolved the issue.
  • Set Fix Version(s), if and only if the resolution is Fixed
  • Set Assignee to the person who contributed the most to its resolution, usually the person who opened the PR that resolved the issue.
• For issues that can't be reproduced against master as reported, resolve as Cannot Reproduce.
• If the issue is the same as or a subset of another issue, resolved as Duplicate
  • Mark the issue that has less activity or discussion as the duplicate.
  • Link it to the JIRA ticket it duplicates.
• If the issue seems clearly obsolete and applies to issues or components that have changed radically since it was opened, resolve as Not a Problem
• If the issue doesn't make sense or is not actionable resolve as Invalid.
• If it's a coherent issue, but there is a clear indication that there is no support or interest in acting on it, then resolve as Won't Fix.

Searching JIRA How to search JIRA for existing issues:

1. Basic:
   1. Visit AGE JIRA
   2. Type query into search box in top right (beware this will return results from all projects)
2. Advanced:
   1. Visit AGE JIRA Advanced Search
   2. Replace the empty quotes with quoted text (such as "cypher")
3. Search Now:
   1. Use the search box below
   2. Search

If a logically similar issue already exists, then contribute to the discussion on the existing JIRA ticket and pull request, instead of creating a new ticket and PR.

This document includes the steps needed to be taken by the release manager to create a successful release candidate. Update the version numbers in the AGE source code, so Postgres can identify which version number of AGE it is using. The extension number in Postgres and Apache releases are synchronized.

Files to update:

Step 1 - Rename CREATE EXTENSION script name:
Rename age--Y.Y.Y.sql to age--X.X.X.sql

Step 2 - Update Makefile:
Update line 62 in Makefile from: DATA = age--Y.Y.Y.sql to: DATA age--X.X.X.sql

Step 3 - Update age.control:
Update line 18 in age.control from default_version = 'Y.Y.Y' to: default_version = 'X.X.X'

Step 4 Add Release Notes:
Update RELEASE with X.X.X release notes

Step 5 update documentation:
update line 46 in doc/conf.py:
from:
release = u'Y.Y.Y'
to:
release = u'X.X.X'

The first step is to create a new release branch. The branch must follow the following naming pattern release/X.X.X where X.X.X is the release version number. In this example upstream is the apache/incubator-age github repository.
git branch release/X.X.X upstream/master
git checkout release/X.X.X
git push upstream release/X.X.X:release/X.X.X

Checkout the tag to a clean folder to avoid files that are ignored by git and remove the git folder. Next up is creating the tar.gz file
git clone --depth 1 --branch X.X.X-rcX
https://github.com/apache/incubator-age.git apache-age-X.X.Xincubating
rm -rf apache-age-X.X.X-incubating/.git
tar -czvf apache-age-X.X.X-incubating-src.tar.gz apache-ageX.X.X-incubating

This part assumes you already have created and registered keys to sign the artifacts, for more information on creating and adding your keys see here
gpg --armor --default-key username@apache.org --output apacheage-X.X.X-incubating-src.tar.gz.asc --detach-sig apache-ageX.X.X-incubating-src.tar.gz
sha512sum apache-age-X.X.X-incubating-src.tar.gz > apache-ageX.X.X-incubating-src.tar.gz.sha512

# Validate
gpg --verify apache-age-X.X.X-incubating-src.tar.gz.asc
sha512sum -c apache-age-X.X.X-incubating-src.tar.gz.sha512

First step is to check out the SVN directory, and create a new directory
svn co https://dist.apache.org/repos/dist/dev/incubator/age
age_release
cd age_release
svn mkdir apache-age-x.x.x-incubating-rcx
Now copy over the following files in this new directory
apache-age-X.X.X-incubating-src.tar.gz.sha512
apache-age-X.X.X-incubating-src.tar.gz.asc
apache-age-X.X.X-incubating-src.tar.gz

Add and commit the files to svn
svn add *
svn status
svn commit -m 'Add release files for Apache age X.XX-rcX'
Check if the files are uploaded here

Mail Template
Subject: [VOTE] Release Apache age (incubating) X.X.X-rcX
TO: dev@age.apache.org

Hi All,

[ INCLUDE SOME TEXT ]

Build instructions can be found in the README included.

The tag to be voted on is X.X.X-rcX [REPLACE TAG] (commit[COMMIT HASH]):
[ URL TO TAG COMMIT ]
The release files, including signatures, digests, etc. can be found at:
[ INCLUDE URL TO DIST RC FOLDER ]
https://dist.apache.org/repos/dist/dev/incubator/age/apacheage-X.X.X-incubating-rcX/

The SHA512 Checksum for these artifacts is:
[ INCLUDE CHECKSUM FROM SHA512 FILE ]

Release artifacts are signed with the following key:
[ ADD URL TO YOUR KEY ON A PUBLIC KEYSERVER ]

For more information about the contents of this release, see:
[ ADD URL TO RELEASE IN JIRA ]

Please vote on releasing this package as Apache AGE (incubating) X.XX!

The vote is open for 72 hours and passes if a majority of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache age (incubating) X.XX
[ ] +0 No opinion
[ ] -1 Do not release this package because ...

Best Regards,
[ YOUR NAME ]

Subject: [RESULT] [VOTE] Release Apache age (incubating) X.XXrcX
TO: dev@age.apache.org

Hello Team,

The vote to release Apache age (incubating) X.X.X - RCX has passed/failed.

+1 (binding)
+1 (non-binding)
+0
-1 (binding)
-1 (non-binding)

Thank you for reviewing this release candidate.
Cheers,
[ YOUR NAME ]


The mail to the IPMC is almost identical to our vote mail, a few extra details are added:
- Vote and Result mail thread
Subject: [VOTE] Release Apache age (incubating) X.XX-rcX
TO: general@incubator.apache.org

Hi All,

[ INCLUDE SOME TEXT ]

Build instructions can be found in the README included.
age community vote and result threads:

Vote:
[ URL TO VOTE FROM https://lists.apache.org/list.html?dev@age.apache.org ]
Result:
[ URL TO VOTE RESULT FROM https://lists.apache.org/list.html?dev@age.apache.org ]
The tag to be voted on is X.X.X-rcX [REPLACE TAG] (commit[COMMIT HASH]):
[URL TO TAG COMMIT]

The release files, including signatures, digests, etc. can be found at:
[ INCLUDE URL TO DIST RC FOLDER ]
https://dist.apache.org/repos/dist/dev/incubator/age/apacheage-X.X.X-incubating-rcX/

The SHA512 Checksum for these artifacts is:
[ INCLUDE CHECKSUM FROM SHA512 file ]

Release artifacts are signed with the following key:
[ ADD URL TO YOUR KEY ON A PUBLIC KEYSERVER ]

For more information about the contents of this release, see:
[ ADD URL TO RELEASE IN JIRA ]

Please vote on releasing this package as Apache age (incubating) X.X.X!

The vote is open for 72 hours and passes if a majority of at least 3 +1 PMC votes are cast.
[ ] +1 Release this package as Apache age (incubating) X.XX
[ ] +0 No opinion
[ ] -1 Do not release this package because ...

Best Regards,
[ YOUR NAME ] To generate and publish a key follow these steps, it is recommended to use your apache email as key alias.
gpg --gen-key
gpg -k [username]@apache.org
# get the ID for your key
gpg --send-keys --keyserver php.mit.edu [KEY ID]
gpg --send-keys --keyserver keyserver.ubuntu.com [KEY ID]

Next step is to add your key to the key file in the Apache SVN repository.
svn co https://dist.apache.org/repos/dist/dev/incubator/age
age_release
cd age_release
gpg --list-sigs [KEY ID] >> KEYS
gpg --armor --export [KEY ID] >> KEYS
svn commit -m "added new public key to KEYS file"

• Code Review Process
• How to Merge a Pull Request
• Coding Style Guide
• Creating Documentation

• Make a commit (or multiple commits) on your local branch.
• Create .patch file(s) of the commit(s).
  • Use git format-patch command.
• Send the .patch file(s) to the reviewer.
  • The title of the email must be "[Review] [JIRA Ticket Name Here] summary-of-the-issue"
    (e.g. [Review] [JIRA Ticket Name] Support changing graph name)
    • If the commit is not for any issues on JIRA, omit " [JIRA Ticket Name Here]". OR make a JIRA ticket
  • The email body will look like this:
    Commit bef50e5d86d45707806f5733695a229f3e295b1a [one blank line] Description
    • The first line is the hash code of the base commit, NOT the commit you've created.
      • This will help reviewers to quickly apply the .patch files.
    • Put proper information to help the reviewer.
  • Attach .patch files.
    • Do NOT rename files. They are named with numbers in order.
    • Do NOT compress them unless the total file size is over 5MB.
• Reply to the last email in the same thread to send a review of it.
  • You can attach some .diff files.
• Reply to the last email in the same thread to send updated patch(es) and opinions.
  • If you rebase commits, state the hash code of the new base commit.
• Repeat 4 and 5.

---

Single Commit for a Single Task

In this case, the commit will be merged into the master branch with the following process.

1. Change the current working branch to the local master branch by running the following command.
   $ git checkout master
2. Make the local master branch up-to-date by running the following command (or any other commands that result the same.)
   $ git pull
3. Change the current working branch to the local task branch that the commit resides in by running the following command.
   $ git checkout
4. Rebase the local task branch by running the following command.
   $ git rebase master
5. Resolve any conflicts that occur during rebase.
6. Change the current working branch to the local master branch by running the following command.
   $ git checkout master
7. Merge the local task branch into the local master branch by running the following command.
   $ git merge

Multiple Commits for a Single Task

Keeping Commit History
Sometimes, having logically separated, multiple commits for a single task helps developers to grasp the logical process of the work that had been done for the task. If the commits are merged with fast-forward strategy, the commits will not be grouped together. Therefore, to group the commits, create an explicit merge commit.
In this case, the commits will be merged into the master branch with the same process above except the last step (step 7).
For the last step, the local task branch will be merged into the local master branch with an explicit merge commit by running the following command. If you omit --no-ff option, the command will do fast-forward merge instead. The above process will result, for example, the following commit history. (This is captured from apache/incubator-age.) There is an explicit merge commit, 69f3b32. Each explicit merge commit groups related commits. Note: There is no commit between an explicit merge commit and the parent commit, which is on the master branch, of the explicit merge commit. This is done by doing rebase before merge.

---

For a full list of coding style guidelines, please refer to the style setup in the clang-format.5 in the AGE git repository. Use 4 spaces per indentation level. (no tab character)

• You can see the same indentation in all environments.

For switch statement, see below. The line length limit is 79 columns, except for strings longer than 79 characters. All braces are on their own line solely. See below. If all the bodies of if/else statement contain a single line, omit braces. See below. One exception is do statement. See the following example. Use the underscore name convention for all variables, functions, structs, enums and define macros. Use typedef only for struct and enum. It must not be used for pointer types. For multi-line comments, use C style multi-line comments.
For single-line comments, use C++ style single-line comments.
See below. Don't align bodies of macros.

• If names are changed or new entries are added, it may produces unnecessary diffs and this makes it harder for you to find lines that are actually modified

When you write a macro that spans multiple lines, don't align \ character.

• If bodies of macros are modified, it may produce unnecessary diffs and this makes it harder for you to find lines that are actually modified.
• It is harder for you to find lines that are actually modified.

For newlines, only \n is allowed, not \r\n and \r. If a pointer variable (including List *) is used as a condition, which means that it is evaluated as true/false value, use it AS-IS. Do not perform explicit comparison with NULL (or NIL). For negation, put ! before it. An error message that is passed to errmsg() starts with a lower case letter.
An error detail/hint message that is passed to errdetail()/errhint() starts with an upper case letter.

---

• Dependencies: python3, python3-sphinx, sphinx_rtd_theme
• Clone incubator-age repository (AGE) (https://github.com/apache/incubator-age)
• Go to the doc folder of the project
• Type make html
• The documents are in _build/html

An example of the commands on Ubuntu follow:

PPMC Members

Name	Email
John Gemignani	john.gemignani@bitnine.net
Josh Innis	josh.innis@bitnine.net
Eya Badal	badaleya@gmail.com
Dehowe Feng	dehowe.feng@bitnine.net
Jasper Blues	jasper@liberation-data.com
Mason Sharp	mason.sharp@gmail.com

Committersv(Not including PPMCs)

Name	Email
Nick Sorrell	nick@cint.io
Andrew Ko	youngseung.andrew@gmail.com
Alex Kwak	take-me-home@kakao.com
Pieterjan De Potter	pdpotter@apache.org

Release	CheckSum & Signature
Download Apache AGE 0.6.0	CheckSum & Signature & KEY Files
Download Apache AGE 0.5.0	CheckSum & Signature & KEY Files
Download Apache AGE 0.4.0	CheckSum & Signature & KEY Files
Download Apache AGE 0.3.0	CheckSum & Signature & KEY Files

Docker Images
Docker Apache AGE 0.6.0

Get help using Apache AGE (Incubating) or contribute to the project on our mailing lists:

• Visit Commits or subscribe for people following commits to the project.
• Visit Developer or subscribe for developers wanting to commit code to the project.
• Visit Users or subscribe for users wanting to learn more about the project.

The Apache Software Foundation takes a rigorous standpoint in annihilating the security issues in its software projects. Apache AGE is highly sensitive and forthcoming to issues pertaining to its features and functionality.
If you have apprehensions regarding AGE’s security or you discover vulnerability or potential threat, don’t hesitate to get in touch with the Apache Security Team by dropping a mail at Security Apache. In the mail, specify the project name AGE with the description of the issue or potential threat. You are also urged to recommend the way to reproduce and replicate the issue. The security team and the AGE community will get back to you after assessing and analysing the findings.
PLEASE PAY ATTENTION to report the security issue on the security email before disclosing it on public domain.
The ASF Security Team maintains a page with the description of how vulnerabilities and potential threats are handled, check their Web page for more Details.

This is an assessment of the Apache AGE podling’s maturity, meant to help inform the decision (of the mentors, community, Incubator PMC and ASF Board of Directors) to graduate it as a top-level Apache project.
It is based on the ASF project maturity model All open items are updated with the latest status. Mentors and community members are encouraged to comment on it, the following table summarizes project’s self-assessment against the Apache Maturity Model.

Category	Description	AGE self asssessment
Code CD10	The project produces Open Source software for distribution to the public, at no charge.	YES. The project source code is licensed under the Apache License, version 2.0.
Code CD20	Anyone can easily discover and access the project's code.	YES. Linked from the website, available via git.apache.org and GitHub at https://github.com/apache/incubator-age
Code CD30	Anyone using standard, widely-available tools, can build the code in a reproducible way.	YES. Anyone with a standard OS can build the AGE extension from the code at the GitHub repo.
Code CD40	The full history of the project's code is available via a source code control system, in a way that allows anyone to recreate any released version.	YES. Releases are cut from Main repository at https://github.com/apache/incubator-age All releases are tagged.
Code CD50	The source code control system establishes the provenance of each line of code in a reliable way, based on strong authentication of the committer. When third parties contribute code, commit messages provide reliable information about the code provenance.	YES. The project GitHub repository, managed by Apache Infra, ensures provenance of each line of code to a committer. Third party contributions are accepted in accordance with the Contribution Guide only.
Licenses and Copyright LC10	The Apache License, version 2.0, covers the released code.	YES. Source distributions clearly state license. Convenience binaries clearly state license.
Licenses and Copyright LC20	Libraries that are mandatory dependencies of the project's code do not create more restrictions than the Apache License does.	YES. The list of mandatory dependencies have been reviewed to contain approved licenses only. See below.
Licenses and Copyright LC30	The libraries mentioned in LC20 are available as Open Source software.	YES. All mandatory dependencies are available as open source software. See below.
Licenses and Copyright LC40	Committers are bound by an Individual Contributor Agreement (the "Apache iCLA") that defines which code they may commit and how they need to identify code that is not their own.	YES. The project uses a repository managed by Apache Infra -- write access requires an Apache account, which requires an ICLA on file.
Licenses and Copyright LC50	The project clearly defines and documents the copyright ownership of everything that the project produces.	YES. All files in the source repository have appropriate headers (see below).Even further, Software Grant Agreements for the initial donations and Corporate CLAs have been filed.
Releases RE10	Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term.	YES. Source releases are distributed via dist.apache.org and linked from the website.
Releases RE20	The project's PMC (Project Management Committee, see CS10) approves each software release in order to make the release an act of the Foundation.	YES. All incubating releases have been unanimously approved by the AGE community and the Incubator, all with at least 3 (P)PMC votes.
Releases RE30	Releases are signed and/or distributed along with digests that anyone can reliably use to validate the downloaded archives.	YES. All releases are signed, and the KEYS file is provided on dist.apache.org.
Releases RE40	The project can distribute convenience binaries alongside source code, but they are not Apache Releases, they are provided with no guarantee.	YES. AGE provides docker files for convenience with the installation and drivers for users to connect to the project.
Releases RE50	The project documents a repeatable release process so that someone new to the project can independently generate the complete set of artifacts required for a release.	YES. Release guide is available describing the entire process. The AGE releases have been performed by different people.
Quality QU10	The project is open and honest about the quality of its code. Various levels of quality and maturity for various modules are natural and acceptable as long as they are clearly communicated.	YES. The project records all bugs in the Apache’s JIRA issue tracker.
Quality QU20	The project puts a very high priority on producing secure software.	YES. Security issues are treated with the highest priority, according to the CVE/Security Advisory procedure. We lean on the data redundancy, authentication and security features provided by postgres.
Quality QU30	The project provides a well-documented, secure and private channel to report security issues, along with a documented way of responding to them.	YES. Website provides AGE security page: https://age.apache.org
Quality QU40	The project puts a high priority on backwards compatibility and aims to document any incompatible changes and provide tools and documentation to help users transition to new features.	YES. Each release contains a “What’s new” on the website containing the release notes (extracted for Jira). The project aims to make no backward incompatible changes within a given major version.
Quality QU50	The project strives to respond to documented bug reports in a timely manner.	YES. The project has resolved >150 issues during incubation.
Community CO10	The project has a well-known homepage that points to all the information required to operate according to this maturity model.	YES. The project website has a description of the project with technical details, and how to contribute. Several issues ahve been flagged as "good first issue" also available at https://github.com/apache/incubator-age/contribute
Community CO20	The community welcomes contributions from anyone who acts in good faith and in a respectful manner, and who adds value to the project.	YES. It’s part of the contribution guide and the current committers are really keen to welcome contributions.
Community CO30	Contributions include source code, documentation, constructive bug reports, constructive discussions, marketing and generally anything that adds value to the project.	YES. The contribution guide refers to non source code contribution, like documentation.
Community CO40	The community strives to be meritocratic and gives more rights and responsibilities to contributors who, over time, add value to the project.	YES. The community has elected 4 new committers during incubation, based on meritocracy.
Community CO50	The project documents how contributors can earn more rights such as commit access or decision power, and applies these principles consistently.	YES. The criteria is documented in the contribution guide.
Community CO60	The community operates based on consensus of its members (see CS10) who have decision power. Dictators, benevolent or not, are not welcome in Apache projects.	YES. The project works to build consensus. All votes have been unanimous todate
Community CO70	The project strives to answer user questions in a timely manner.	YES. The project typically provides detailed answers to user questions within a few hours via dev@ mailing list and users@ mailing list.
Community consensus CS10	The project maintains a public list of its contributors who have decision power. The project's PMC (Project Management Committee) consists of those contributors.	YES. The website contains the list of committers and PPMC members.
Community consensus CS20	Decisions require a consensus among PMC members and are documented on the project's main communications channel. The PMC takes community opinions into account, but the PMC has the final word.	YES. The project has been making important decisions on the project mailing lists. Vast majority of, if not all, decisions have had a consensus without any PPMC action needed. We are working on making it better.
Community consensus CS30	The project uses documented voting rules to build consensus when discussion is not sufficient.	YES. The project uses the standard ASF voting rules. Voting rules are clearly stated before the voting starts for each individual vote.
Community consensus CS40	In Apache projects, vetoes are only valid for code commits. The person exercising the veto must justify it with a technical explanation, as per the Apache voting rules defined in CS30.	YES. The project hasn't used a veto at any point and relies on robust code reviews.
Community consensus CS50	All "important" discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions 11 that affect the project are also documented on that channel.	YES. The project has been making important decisions on the project mailing lists. Minor decisions may occasionally happen during code reviews, which are also asynchronous and in written form. We're working to improve in this area.
Independence IN10	The project is independent from any corporate or organizational influence.	YES. While one particular organisation is keenly interested in the development of AGE the community is autonomous in product design and development
Independence IN20	Contributors act as themselves, not as representatives of a corporation or organization.	YES. The committers and contributors act on their own initiative without representing a corporation or organization. Many contributors are employees of a single company who has interest in the success of AGE but there are many entirely independent contributors.