Hacker News new | past | comments | ask | show | jobs | submit login

The issue of a rigid release schedule! April means April whether you miss out on something or not.



You still end up having to make compromises no matter what.


One method allows for you to determine which compromises are acceptable, while the other does not.


Not really. Let's consider an alternate flexible version that stretches up to 2-3 months outside of emergencies. Versus a non-flexible version that stretches 0 months outside of emergencies.

If you compare the flexible version targeted at June, and the non-flexible version targeted at August, you'll find that they're making almost the exact same compromises.

Nothing ever stops you from using an earlier version if it's more stable. So both schedules get to chose from multiple versions. Maybe flexible chooses from 6 month old to 3 months in the future code, via delaying. But non-flexible can choose from 9 month old to 0 month old code. It works out the same, and the only difference is how you label it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: