Release v0.1.5

CHANGELOG.md

@@ -4,17 +4,27 @@
 
 ### Features
 
-- Added `EventSet.tick_calendar()` operator.
-- Added `EventSet.where()` operator.
+### Improvements
+
+### Fixes
+
+## 0.1.5
+
+### Features
+
 - Added `EventSet.filter_moving_count()` operator.
 - Added `EventSet.map()` operator.
+- Added `EventSet.tick_calendar()` operator.
+- Added `EventSet.where()` operator.
+- Added all moving window operators to Beam execution backend.
 
 ### Improvements
 
 - Print `EventSet` timestamps as datetimes instead of float.
 - Support `sampling` argument in `EventSet.cumsum()` operator.
 - Using utf-8 codec to support non-ascii in string values.
 - New `tp.types` module to facilitate access to types used throughout the API.
+- Relaxed version requirements for protobuf and pandas.
 
 ### Fixes
 

pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "temporian"
-version = "0.1.4"
+version = "0.1.5"
 description = "Temporian is a Python package for feature engineering of temporal data, focusing on preventing common modeling errors and providing a simple and powerful API, a first-class iterative development experience, and efficient and well-tested implementations of common and not-so-common temporal data preprocessing functions."
 authors = [
     "Mathieu Guillame-Bert, Braulio Ríos, Guillermo Etchebarne, Ian Spektor, Richard Stotz <gbm@google.com>",
@@ -73,7 +73,7 @@ coverage = "^7.3.1"
 [tool.poetry.extras]
 beam = ["apache-beam"]
 tensorflow = ["tensorflow"]
-all = ["apache-beam","tensorflow"]
+all = ["apache-beam", "tensorflow"]
 
 [tool.black]
 line-length = 80

temporian/__init__.py

@@ -25,7 +25,7 @@
 # from temporian.module import submodule as _submodule
 # del _submodule
 
-__version__ = "0.1.4"
+__version__ = "0.1.5"
 
 # Register all operator implementations
 from temporian.implementation.numpy import operators as _impls

tools/RELEASE.md

@@ -4,16 +4,20 @@ The Python package is built and published to PyPI when a new release is created
 
 To create a new release, follow these steps:
 
-1. Update the version number in `pyproject.toml` and `temporian/__init__.py` to the new version number (e.g. `1.3.2`).
+1. Open a new branch with the version's name, e.g. `v1.3.2`.
 
-2. Edit the [changelog](../CHANGELOG.md) by moving the latest changes to the new version's section and clearing the latest changes one.
+2. Update the version number in `pyproject.toml` and `temporian/__init__.py` to the new version number (`1.3.2` in this case).
 
-3. Commit your changes and open and merge a PR to `main`, titled `Release v1.3.2` in this case.
+3. Edit the [changelog](../CHANGELOG.md) by moving the latest changes to the new version's section and clearing the latest changes one.
 
-4. Wait for the testing actions to pass on the merge commit.
+4. Check the PRs merged since the last release and add any missing important changes to the changelog.
 
-5. Create a new [GitHub release](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release) with the new version's name prepended with `v`, e.g. `v1.3.2`. Add this version's changelog to the release notes.
+5. Commit your changes and open and merge a PR to `main`, titled `Release v1.3.2` in this case.
 
-6. Publish the Release. This will trigger the GitHub Action that builds and publishes the package to PyPI, and will point the /stable docs to this new version.
+6. Wait for the testing actions to pass on the merge commit.
 
-7. Pull `main`, tag the latest commit as the new stable version with `git tag last-release -f`, and push it with `git push origin last-release -f`. This gives us a way to easily find the latest stable version of the code in the GitHub tree (used for example by the tutorial notebooks to not open an unreleased version of the notebooks).
+7. Create a new [GitHub release](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release) with the new version's name (`v1.3.2` in this case) as both the tag and the release name. Click on `Generate release notes`, and add this version's changelog on top with the heading "## Release notes".
+
+8. Publish the Release. This will trigger the GitHub Action that builds and publishes the package to PyPI, and will point the /stable docs to this new version.
+
+9. Pull `main`, tag the latest commit as the new stable version with `git tag last-release -f`, and push it with `git push origin last-release -f`. This gives us a way to easily find the latest stable version of the code in the GitHub tree (used for example by the tutorial notebooks to not open an unreleased version of the notebooks).