Changing the release cycle

[Matt Farmer]

We’ve had a lot of disjointed conversations about this in the past, but I want to open

one up again. :)

I’d like to suggest that we start doing minor point releases of Lift at fixed intervals.

Something like every 2 or 3 months. I think there are a lot of reasons this could be

good, but the biggest (for me) is the positive feedback loop of getting my changes

released on a regular interval and knowing when that is.

We released Lift 3 on November 13th. At a rate of one point release every three

months, 2017’s release cadence would look something like:

Jan 15 — 3.1

Apr 15 — 3.2

Jul 15 — 3.3

Oct 15 — 3.4

Or, if we chose the more frequent “every two months” option:

Jan 15 — 3.1

Mar 15 — 3.2

May 15 — 3.3

Jul 15 — 3.4

Sep 15 — 3.5

Nov 15 — 3.6

The idea here is that these point releases are very small, but also very regular.

They may only include one or two PRs, but my thought/hope is that constructing

a cadence like this will create some momentum for people to contribute.

Thoughts?

—
Matt Farmer | Blog | Twitter
GPG: CD57 2E26 F60C 0A61 E6D8  FC72 4493 8917 D667 4D07

[Diego Medina]

As long as going from 3.0.1 to 3.6 (as examples)  doesn't require users to make big changes to their apps, I'm all for more often releases. But if we will start requiring users to have to upgrade to each release point, that will become a pain, because not everyone has time to keep track of new versions of lift, deploy them on staging servers, do internal testing, etc, plus their normal work related testing and adding features to their actual apps.

The other thing to consider are modules, right now, a module is compiled against the lift version, this would mean that a typical module would have to cross compile with a large number of lift versions.

Thanks

Diego

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

[Richard Dallaway]

Good point Diego — in module land at the moment, modules are published against 2.5, 2.6, 3.0 and so on. The assumption is that we’re stable on minor releases (we can treat modules for 3.0.0 as OK for use with 3.0.1 etc), but there could be API changes between 3.0 and 3.1 - so we rebuild modules on those changes.

If we’re making API changes every three months, so be it.  But if it’s a release cadence for small changes, we could just increment the x part of 3.0.x and then the modules aren’t changing as regularly.

Richard

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

[Matt Farmer]

We could release at a regular cadence and just make a call at time of release what to version it based on the changes. (And as a result whether or not to rebuild modules.)

—
Matt Farmer | Blog | Twitter

GPG: CD57 2E26 F60C 0A61 E6D8  FC72 4493 8917 D667 4D07

[Peter Petersson]

As long as the new release is not a major/minor number change the modules don't have to be rebuilt but if it is the modules has to be rebuilt regardless if they are affected by the change or not simply because we have a Lift minor number change dependency for modules.

As a module maintainer I think having at most 2-(3?) releases / year would be preferable and given proper notice modules could be (most of the time) built against the latest RC and hence released and ready on time for the new Lift release.

Keep in mind that on top of the suggested 2-3 point releases above, modules also have there own release cycles where most of the work has gone in, that work might or might not be ready for release at the time for a Lift release witch means that module maintainers has to be prepared to branch of from a stable point (likely from the latest release) just to compile test, tag and release for all Lift major/minor number bump releases.

Best regards Peter Petersson

[Diego Medina]

Thanks for your input Peter, I agree we shouldn't add a lot more work for module maintainers and I see that having many releases of Lift per year would do just that.

Lift 2.6 was released on January 2015, Lift 3.0 was released on Nov 2016, that was almost two years, definitely a really long time (granted we had many M / RC releases in between and we got some huge changes), but at this point I don't think we could jump all the way to releasing every 2/3 months.

A good middle ground would be to aim at releasing the next version of Lift six months from 3.0 , that goal would hopefully be realistic, and will give us enough real experience on how to handle the modules, and all the work associated with a release.

And pointing fingers to myself, the lift site doesn't even have any information about the final release of 3.0 or that 3.0.1 was built for Scala 2.12.1, what I mean by pointing this out is, there are a lot of steps involved in releasing a new version and I don't think right now we are ready to have very often releases.

Thanks

Diego

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Antonio Salazar Cardozo]

I would suggest given the module limitation that we make the regular release

cadence be based around milestone releases. Indeed, this was the main goal

of the milestone releases before the 3.0 cycle: they were regular releases that

were considered stable, but not final, and did not necessarily include module

updates. Less frequently, minor releases would occur that would roll up milestone

releases. Support was officially provided for the latest minor release + the latest

milestone release (IIRC), though in practice the ML would generally tolerate a bit

of jitter around those versions. I think now that 3.0 is out, returning to that would

make sense.

Looking at the calendar in a 2-month view, but including RC cycles, we might have:

Jan 15 — 3.1.0-M1

Mar 15 — 3.1.0-M2

May 15 — 3.1.0-M3

Jun 15 — 3.1.0

Jul 15 — 3.2.0-M1

Sep 15 — 3.2.0-M2

Nov 15 — 3.2.0-M3

Dec 15 — 3.2.0

We could kick off an RC cycle for a minor release 1 month after the third milestone

release, and at that point we'd branch off for the minor release and make master the

next milestone (i.e., above, on June 1st, we would branch off lift-3.1.0 and release it

as RC1, while master would become 3.2.0-SNAPSHOT with an eye towards 3.2.0-M1).

Thoughts?

Thanks,

Antonio

[Peter Petersson]

LGTM 

Best regards Peter Petersson 

[Antonio Salazar Cardozo]

Any further thoughts here? Matt, does the milestone-based release satisfy your

desire for more frequent releases? Diego, Richard, does this address your concerns

on module releases, etc?

I'm currently working on moving the Lift site itself to be able to use Markdown; once

I've done that I'm going to add a script to it that can pull down the latest release notes

and create a quick version of a release announcement for the site so that the process

of posting a release to the site is relatively painless.

Thanks,

Antonio

[Diego Medina]

Having more frequent RC and Milestone releases => +1

What I'm not so sure about is branching off on the first RC and start adding new code for the next version to master, reason being, we are a small group of people, if we start adding new **cool** features to master while RC for the previous is going on, we'll end up splitting our chances of getting more people to try out RC

Thanks

Diego

[Richard Dallaway]

Yes, milestone releases work for me.

Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

[ti com]

You can use MiMa to make sure a point release is binary compatible

[Antonio Salazar Cardozo]

On Sunday, January 29, 2017 at 6:02:23 AM UTC-5, ti com wrote:

You can use MiMa to make sure a point release is binary compatible

This sounds like an excellent plan.

What I'm not so sure about is branching off on the first RC and start adding new code for the next version to master, reason being, we are a small group of people, if we start adding new **cool** features to master while RC for the previous is going on, we'll end up splitting our chances of getting more people to try out RC

Hmmm… I get this concern, but I think in practice this largely won't be a problem. In

particular, I would consider this to be more useful for continuing forward development

in cases where the RC cycle gets extended due to a bug fix or two. The master branch

would build the SNAPSHOT, and I would think that most folks running Lift would be

running off of a final or milestone release once we have a more regular release cadence

going.

That said, I'm not particular opposed to saying “we don't merge PRs until an RC cycle

is finished”, since I don't think that'll make a material difference in the short run.

Thanks,

Antonio

 

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

[Matt Farmer]

Sorry, all, dropped the ball on this thread due to some personal stuff going on around the end of the year. Thanks Antonio for finding and reviving it. =)

Matt, does the milestone-based release satisfy your
desire for more frequent releases?

Yes, this would satisfy my desire for more frequent releases.

That said, I'm not particular opposed to saying “we don't merge PRs until an RC cycle
is finished”, since I don't think that'll make a material difference in the short run.

So, personally there’s a mental tax to not being able to merge PRs. Case in point - my PR to add improved tuple support to lift-json has been in flight for more than a year. There was zero possibility of me getting the reward of seeing the merge so my momentum and motivation to work on it was 0. Part of this release cycle was to try and engineer around my own needs for rewards to hopefully make me more productive in the Framework code.

However, I’m open to experimenting.

That said, we’ve already missed January 15… should we cut a 3.1.0-M1 sometime this week and have the date be Feb 1ish?

Thanks,

Matt

—
Matt Farmer | Blog | Twitter
GPG: CD57 2E26 F60C 0A61 E6D8  FC72 4493 8917 D667 4D07

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

[Antonio Salazar Cardozo]

I'm in for that.

[Matt Farmer]

Excellent, let’s do it then.

Diego, if you don’t have time to do the build I can! =)

Uh. By the way are we building on JVM 7 now or JVM 8? lol

—
Matt Farmer | Blog | Twitter
GPG: CD57 2E26 F60C 0A61 E6D8  FC72 4493 8917 D667 4D07

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

[Diego Medina]

Great, we use java 8 and the build is running, will check on it in the morning.

Thanks

Diego